relax! it’s just 0s and 1s

as you know, VS introduced its own unit testing framework, inbuilt for TDD. there are some very good things I like about it.

1. it removes the dependency from any external unit testing libraries like NUnit. (though NUnit was worth all its bits)
2. it is part of the build process and we can use the VSTS test runner (MSTest.exe), if the test cases need to be run separately, rather than from the IDE.
3. Code coverage can be done using the test config file.
4. it also provides support for deploying the required support files for the test cases to run successfully. (xml files, config files etc) explained later.
5. the code can be debugged using the test cases.
6. regression testing is very reliable, when features change in your application.
7. The test cases can be organized using the ‘Test Manager’

 Let us take a small and simple example. I have a sample ‘Add’ method which I want to test:

public int Add(int a, int b)
{
    return a + b;
}

To create a Unit test for this method/project, you could just right click inside the file containing this method >> Create Unit Tests and you can have the whole test project template within seconds.

The Unit Test is as follows:

[TestMethod()]
public void AddTest()
{
    Calculator target = new Calculator();
 
    int a = 8;
 
    int b = 16;
 
    int expected = 24;
    int actual;
 
    actual = target.Add(a, b);
 
    Assert.AreEqual(expected, actual);
}

• The Test class is attributed with the [TestClass()]attribute.
• The Test method is attributed with the [TestMethod()]attribute.
• There are also some other interesting attributes at the Test Method level:
• [ ExpectedException(typeof(Exception))] >> This attribute makes the unit case, expect the type of exception provided, and does not fail the test case when that exception occurs. This is usefule if there are -ve test cases. (E.g FileNotFoundException, Business Exceptions etc)
• [Description("Test Case Id: 2.34 Add two valid numbers.")] >> This attribute makes it easier to name a test case according to your test case list. Whenever the test case fails, you can see the Description and identify the exact test case which failed.
• [WorkItem(9999)] >> This attribute is helpful in associating the test case with a work item in your scrum/tfs/project management tool.
• [Ignore()] >> If there are some test cases, which need not be executed at this point of time, this attribute can be used.

 TestSolution.vsmdi

• This file is basically what the test manager controls. It is used to group all the test cases in the solution.
• As you notice, this file is a solution level item and hence common to all the project unit cases in your application.
• You can create ‘New Test Lists’ and arrange your test cases as per Projects/Business Objects/Layers etc.
• Once arranged, the specific test cases can be executed.

localtestrun.testrunconfig

• This is the common configuration file for all the test cases in your application.
• It controls the naming scheme for the output folder it creates, where the test run results are stored.
• Code Coverage can be enabled for the assemblies.
• The Deployment option provides the support files, which you may want to deploy for the test cases to run successfully.
• It also provides a ‘Startup’ and ‘Cleanup’ script option to be run, before and after the test case run.

there are other cool features of the Unit Testing framework like, reading test data from data sources, private accessors, web tests, load testing, linking it to external test controllers and agents etc..

 there’s a solution to every problem; given enough time and money..