To help developers (projects) deliver robust, industrial strength code, Microsoft's created her "defence in depth" strategy. This strategy aims to test for bugs at every stage in a project, aiming to catch them as early as possible. Microsoft thinks this can be done by:
•Unit testing, to test the basic functionality of every method
•Code reviews, to analyse code for coding errors prior to checking it in
•Frequent builds, to make sure that no changes have broken the application
The good thing about Visual Studio (Team System) 2005 is that it helps projects delivering quality code by providing a new set of tools.
Let us look a little bit more to the new testing features of Visual Studio Team System:
Visual Studio 2005 not only includes a set of tools that better supports testing; it also supports the Test Driven Development (TDD) methodology. This methodology lets tests drive the production of code, ensuring that tests reflect what the code is supposed to do and that all methods in the public interface are tested.
Some of the essentials of TTD are:
- tests reflects the specifications and are written before any code that implements the requirements
- The aim is to pass the test
- Once all the tests are passes, the code is complete
One of the good things about unit tests is that it provides the possibility to execute regression tests during the life cycle of the project. This makes it fairly easy to ensure a change to one piece of code didn’t break any other piece of code. Another advantage of writing unit test (before the actual code!) is that this improves the overall design of the software. When using TDD, tests are always written before the code itself. The first time only a stub is created just to satisfy the compiler for the test. After that the body (implementation) is written of the code that is tested just until the test passes.
After the unit test passes, there is time for any refactoring of the code (if necessary) to improve the design.
TDD aims to create tests during development and not at the end of the project (if there is time left)
To make writing unit tests easier and more common, Visual Studio 2005 provides a unit testing framework out of the box. For those of you working with NUnit in the past, this framework will look very familiar. (Of course this is purely based on coincidence and has nothing to do with the inventor of NUnit now working for Microsoft.)
This unit testing framework is available in both the Team Developer and Team Tester of Visual Studio so unit test created by developers can be executed by the testers in the team. The testing framework and testing tools are fully integrated within the Visual Studio IDE so testing can be done without leaving Visual Studio.
When using Team Foundation Server (TFS), all gets even better. TSF integrates activities of the developers and testers; testers are notified when a developer checks in a piece of code (of course with the necessary unit tests!) and developers will be notified when the testers encounter a bug in the code. Without using TFS it is not possible to check in unit tests and test results cannot be stored in the projects repository.
When using the unit test framework within Visual Studio all test classes are stored in a separate assembly (at least this was what I found in the December CTP of VSTS). Personally I like the “strategy” of Enterprise Library a little better. Within Enterprise Library all test classes are provided within the implementation assembly. All in a separate folder within the project called “.Tests”. Maybe there is a very obvious reason to store the unit tests in a separate assembly but I haven’t found one yet.
The good thing is that there is a Test Explorer available within Visual Studio that makes it very easy to run a set of tests. This tool makes it even possible to only execute one or more categories of tests.
Another new and very useful feature of Visual Studio Team System is the integrated code coverage. This makes it very easy to validate if the unit tests for a piece of code cover all code paths. The actual Code coverage can be displayed in a percentage or within the code editor itself.
Knowing that Team System makes it possible to reject code that isn’t covered by unit tests for at least ‘x’ percent, it becomes more and more difficult to produce poor code!