MSTest

MSTest is a framework that provides the methods and assertions for writing and executing unit tests in C#.

C# Attributes

In C#, attributes are formalized bits of information about a program. They operate somewhere between actual code syntax and a comment on the code. Attributes do not directly affect the code they annotate, but they do supply information to the compiler. An attribute is enclosed in square brackets, [], and placed above the item it decorates.

To run unit tests using the native tools available in Visual Studio, the attributes [TestClass] and [TestMethod] are used to indicate that certain classes and methods should be treated as test cases. We describe how to use these in the examples that follow.

Testing Setup

To test a simple .NET Core console project, we add an MSTest project into the same solution. An MSTest project is a console project with an added MSTest dependency.

Turn your attention to the reading examples repo . Inside the solution, we have two projects, Car and CarTests. The Car project is a simple .NET Console app like the others you have encountered in this course so far. CarTests is a new type of project, MSTest Project.

On a Mac, to select this type of project looks like so:

On a Windows:

MSTest is a C# testing framework. When we create a Visual Studio MSTest Project, the necessary API and classes are added as dependencies of the CarTests project. A dependency is a separately developed program or piece of code that another program or piece of code uses to carry out its function. Our C# tests will depend on MSTest code.

Along the same lines, since CarTests tests the methods inside of Car, we must add the Car project as a dependency of CarTests.

Right click on the Dependencies directory in CarTests and add a project reference to the Car project.

Car and CarTests

Open the Car class and look around. Here, we provide a class, Car, with basic information about a make, model, gas level, and mileage. We also give it getters, setters, and a few other methods.

In the same project, the Program class prints the make and model of a given Car object. Run the project to verify it works. Now, open CarTests. It’s empty, save for a few TODOs. Let’s tackle the first TODO to make a new empty test. Starting with an empty test lets us validate that we can use MSTest in our current environment.

[TestClass] and [TestMethod]

Another benefit of coding in an IDE, Visual Studio contains its own test runner. A test runner is simply a tool to execute tests and deliver their results. In order to indicate that CarTests contains unit tests that we want the test runner to run, we must give it the [TestClass] attribute. As you might guess, [TestMethod] annotates a method to signal it as a test case. Both of these attributes come to us via the Visual Studio test runner.

In CarTests, on top of public class CarTests, add [TestClass]. Then, create the following empty test underneath the first TODO. As usual, be sure write this code rather than copy/paste it:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

   namespace CarTests
   {
      [TestClass]
      public class CarTests
      {
         //TODO: add emptyTest so we can configure our runtime environment
         [TestMethod]
         public void EmptyTest() {
            Assert.AreEqual(10,10,.001);
         }
         // ... other TODOs omitted here
      }
   }

Our empty test is aptly named EmptyTest() as a description of its role. This test does not follow the AAA rule from our testing best practices, as it jumps straight to asserting. Nor is it relevant, for that matter. The goal of this empty unit test is not to demonstrate all of our best practices , but rather, to verify that our testing setup is in place.

The three arguments in our test care defined as “expected”, “actual”, and “delta”. This empty test asserts an expected value of 10 to equal an actual value of 10, with an accepted .001 variance.

Of course, 10 equals 10. But let’s run it so we know our test runner works.

Like running console projects, there are many ways to run unit tests and view the results. Here are some options to try:

Mac Users: Running Tests

For Mac users, run the CarTests project just like you would any other project.

Windows Users: Running Tests

For Windows users, you’ll want to find and open the Test Explorer panel. If you don’t already have it docked, you can find it listed in the top Test menu.

With the panel open, select the Run All Tests option.

All Users: Output and Adding More Tests

Once you run the test, you will see a new output panel with a green check mark indicating the test passed and a message stating the test passed.

We know now how the test runner behaves when a test passes and can begin the real work of unit testing the Car class. One responsibility of the Car class constructor is to set its initial gasTankLevel field. This field is determined by the constructor argument for gasTankSize .

Car.cs:

17
18

   // Gas tank level defaults to a full tank
   GasTankLevel = gasTankSize;

This class-specific behavior is a good item to test. Under your second TODO, write a test to verify that the constructor sets the gasTankLevel field.

16
17
18
19
20
21
22

   //TODO: constructor sets gasTankLevel properly
   [TestMethod]
   public void TestInitialGasTank()
   {
      Car test_car = new Car("Toyota", "Prius", 10, 50);
      Assert.AreEqual(10, test_car.GasTankLevel, .001);
   }

Here, we give the test a descriptive name, TestInitialGasTank(), initialize a new Car object, and test that the constructor correctly sets the gasTankLevel field.

We’ve done our best to address testing best practices :

1. The AAAs

   1. We arrange the one variable our test requires: test_car.
   2. We act on the Car constructor method as well: new Car("Toyota", "Prius", 10, 50);.
   3. We assert that the expected value of 10 will equal the actual value returned from getting the tank level (test_car.GasTankLevel).

2. Deterministic

   As it is written, we expect that our test will always pass.

3. Relevant

   This is our first real test, so we don’t yet have much to group it with. That said, the test assesses a method in Car and is situated in a class called CarTests, so it meets the minimum requirements or relevancy. The next section gives us another attribute to use to help group testing variables.

4. Meaningful

   Our test evaluates a simple field assignment but it is not trivial. The line in the constructor being tested is not very complex, but this makes for a good unit test. We want to make sure the basic functionality of our class works as we expect.

Run CarTest to see that both tests pass.

[TestInitialize]

While [TestClass] and [TestMethod] are required to run tests, there are many other attributes you may find useful as your test files grow in scope. One such item to know is [TestInitialize]. Methods with the attribute [TestInitialize] will run before each test method is run in a class.

In the case of CarTest, it would be nice to not need to create a new Car instance for each test we write. In your TestInitialGasTank() method, remove the line initiating test_car. Above your relevant test, add the following [TestInitialize] method:

16
17
18
19
20
21
22

   Car test_car;

   [TestInitialize]
   public void CreateCarObject()
   {
      test_car = new Car("Toyota", "Prius", 10, 50);
   }

Now, run the test project and ensure your test still passes.

[TestCleanup]

[TestCleanup], conversely, defines a set of conditions to be met after each test in a suite is run.

You can find more information on this attribute and other items available in the Visual Studio testing namespace here .

Common Assert Methods

In addition to the very commonly used Assert.AreEqual() method you see above, here are a few other methods you should have in your unit testing playbook.

Checkout the Assert class for a full listing of methods.

Check Your Understanding