The last blog post in the series introduced some of the new features within Visual Studio 2012, applicable to Test Driven Development (TDD). This blog post is going to continue to further present some more features of Visual Studio 2012 in this domain.
Management of unit tests via Test Explorer
The first impression when opening the “Test Explorer” window is a very positive one. Here are the principal changes when compared to Visual Studio 2010:
- The “Test View” and “Test Results” windows have been deleted and consolidated into the “Test Explorer” window. This is going to streamline the interaction between development (the code) and tests.
- The interface is simple but efficient: all information is accessible via a simple mouse click in a very intuitive way.
- Unit tests are grouped by their status (failed, passed,…), failed tests are shown on top, a double mouse click allows for accessing the code source of a test (no need to open an external window anymore).
- It is now much easier to execute a code coverage analysis. In previous versions this was not handled in a very intuitive way, since you had to create a configuration file, start the analysis via the Visual Studio menu and then open the adequate results window. In Visual Studio 2012 everything was consolidated and is now integrated in the “Test Explorer” interface.
Post Build Test Runs
A best practice when adhering to TDD principles is to execute unit tests as soon and as much as possible for being able to identify bugs, misbehaviors and regressions. There is a new feature, called “Post Build Test Runs”, in Visual Studio 2012, which allows for automatically unit test execution after each compilation. The feature can either be activated via the menu under “Test/Test Settings” or directly from within the “Test Explorer” window. When using this features, unit test are executed on a separated and dedicated thread, so there is no impact on developer efficiency.
Migration of unit tests from Visual Studio 2010 to Visual Studio 2012
As you might know, there a multiple difficulties and bugs, when migrating unit tests from Visual Studio 2008 to Visual Studio 2010, because the migration is not very transparent and sometimes even somewhat complex. In some cases you even have to migrate to the .NET 4.0 Framework to make everything work correctly!
I can assure you that there are no such migration problems, when trying to migrate from Visual Studio 2010 to Visual Studio 2012. This is partly due to the fact that most of the unit test components are the same between those two versions of Visual Studio. The library is still Microsoft.VisualStudio.QualityTools.unitTestFramework.dll in its version 10.0.0.0, which is still based on .NET runtime v2.0.50727.
Fakes Framework (Stubs and Shims)
The “Fakes Framework” based on the “Moles” project, created by the Microsoft Research team, is now exclusively integrated into the “Ultimate” version of Visual Studio 2012 (and sadly only in this version!).
The goal of this framework is to aid development teams in producing unit tests rapidly and easily. For this, the “Fakes Framework” adds 2 notions:
- Stubs: they provide automatic mock implementations of interfaces or abstract classes, that can be used in unit tests for being able to isolate parts that need to be unit tested.
- Shims: they allow for runtime interception and redirection of method calls to specific objects. For example , they may be used to mock objects, which normally can’t be mocked due to access restrictions in the .NET framework. By using Shims it is possible to redirect calls to these objects with calls to objects that provide your own implementations.
There are however some restrictions. One restriction is that classes included in the “mscorlib” namespace cannot have any “Fake Assemblies”. Unfortunately, you cannot create any Shims for the “System.Configuration.ConfigurationManager” class for example.
The “Fakes Framework” provides some real advantages, when compared to existing mock testing frameworks such as RhinoMock, because developers do not need to modify their functional code for being able to execute unit tests.
In my next blog post I am going to show you how to practically use all of those new features and apply them to Test Driven Development. You are going to see a full cycle of TDD using Visual Studio 2012 !
1 comment:
Visual Studio Test Explorer helps you include device examining in your growth process. You can run assessments from several test tasks in a remedy and from test sessions that are part of the value tasks.
Post a Comment