Unit Testing
Greetings! Hope you have had a great start to the New Year! I am happy to continue the series on Testing with the next post.
In this blog I want to share with you what we are doing with Unit Testing in our current shipping products.
Unit Testing is where engineering support/developers are able to ensure that code/APIs works as expected. Visual Studio started to include Unit Testing with the 2005 release of Team System, in 2008 this was added to the Professional Edition as well.
Unit Testing in VS allows users to write tests, with the aid of visual helpers, that populate Test Methods and their attributes. These methods can then be edited to produce valid tests, this enables lots of users to leverage Unit testing as a key part of ensuring quality early in the cycle of development.
When we look at the process of writing a test (any test not just Unit Tests) we can break it down into 3 phases:
Write
This is where tests are constructed, when we look at a Unit Test it is simply code, decorated by attributes (a frequently used technique in .Net programming). A common pattern for test code follows an Arrange, Act and Assert approach, where first the state is arranged (variables assigned etc), then the method under test is called (in general testing one method per unit test is a good practice) and finally an assert proves/disproves that the state changed as expected by the test.
Visual Studio includes some helper UI to generate test project, class and methods for you to streamline the work required to get to actually writing the tests, however tests are just .Net code written in VB, C# or Managed C++ and so use familiar APIs and skills.
Fig. 1 Create Unit Tests and Test Project Dialog, launched by right clicking in the Class under test
Fig. 2 A generated Unit Test from the previous dialog, with data entered by the user and TODO comments removed
Fig. 3 The same class but tested from inside a web project. Note the extra attributes to specify this test should be run under ASP.Net
Run
Once tests have been defined then these are executed, either interactively through the VS IDE using keyboard or mouse actions(right clicking in a class and the menu/toolbar provide this option) or in a lights out fashion using the command line test execution engine, MSTEST.EXE. There is also integration to execute tests via a Team Build task if you are using a common build server. In addition if you run Unit Tests from Test Edition then you can use a Controller /Agent combination(called a Test rig) to execute the tests using multiple different computers.
Analyze
Once the tests have been run the results can be reviewed.
Fig. 4 Test Results view after successfully running the 4 tests generated earlier
If using Development or Test Edition then additional data like Code Coverage can be viewed it’s also possible to publish results to a TFS Server to be shared and reported on, this can be especially important if the tests are running as part of a Team Build process.
Fig. 5 The Code Coverage view (with results) that is usable after enabling code coverage for a Test run. We can see that one method (Divide) only has 60% coverage.
Fig. 6 Drilling into the Divide method based on the results on the previous dialog, we can see the green lines have been covered by the test and the red lines have not
The process can then start again with new tests or editing/enhancing the existing tests, it’s a common practice to develop a test with a single set of data values and then once it is working to add data binding to the test to allow many data combinations to be evaluated.
In addition it is possible to include a Unit Test as part of a Load Test, we’ll talk about that more in later posts and especially some of our community projects where it’s possible to use Unit Tests to generate load against SQL Server or WCF based services.
In VSTS 2008, we spent time to make unit testing more efficient so you can execute your unit tests quickly. For example, we included keyboard shortcuts that make it easier to run Unit Tests without using the mouse. In VSTS 2005 we deployed all assemblies to a directory and this was time consuming and filled up hard drives. In 2008 we added the ability to control these deployments, by default only 25 are kept around but it’s also possible to disable deployment completely, this speeds up test execution and also reduces the amount of disk space required.
As software demands increase, technologies get more distributed, and new innovation occurs unit testing will be a key way to bring quality earlier in the application lifecycle and enable developers and tester alike to ensure software quality is built into the application, not added to it at a later time.
You can get further details of this technology at the following places:
How Do I Videos
Manage Test Results and Results Files
MSDN