Tutorial test driven development with Visual Studio 2012

TEST DRIVEN DEVELOPMENT WITH VISUAL STUDIO 2012
Author: Hong Le Van Page 1 28/07/2015
TUTORIAL: TEST DRIVEN DEVELOPMENT
WITH VISUAL STUDIO 2012
This blog post is going to talk about Test Driven Development (TDD) in an Agile environment using
the latest Visual Studio 2012 features and how that is going to help you to be more efficient and
productive. The goal of this post will be to show you some of the new features within Visual Studio
2012, that are going to help you when trying to apply the TDD approach. The first parts are more
theoretical, while as the last part will be fully practical, since we are going to implement some example
code using TDD.
Contrary to traditional software development methodologies and processes, where writing unit test is
often done as last step after code implementation, TDD consists of writing unit test upfront as first step
in the software development cycle. No development can be started without having implemented the
corresponding unit tests. You understand that TDD has large impacts on the organization of your teams.
The following are the different steps when applying Test Driven Development:
 Write a unit test for a new functionality, then validate that the test fails, since its
implementation has not been realized
 Implement the minimum code necessary to pass the test, then validate that the test passes
successfully, meaning that the expected behavior is now provided by the implementation
 Refactor and optimize your code, the unit tests ensure the coherence of the functionalities
Using TDD helps in obtaining a code source that is very reliable, predictable, robust - and after
refactoring - highly optimized. Unit tests ensure a correct behavior, independently from where it is
going to be used, resulting in a code source that will work as expected under any circumstances.
For being able to create good unit tests, you have at first to think about the conception and software
design of your application. You must not hurry into doing your implementations, before being clear
about your objectives (which should be true for any development, but sadly often it is not).
Conceptual errors can be detected and resolved much quicker and in a much more efficient way. As
explained the implementation is started only after the conceptual phase has been validated and tested
via thorough unit tests. In this case, your unit tests become much than just tests. They become some
sort of general specification, describing “units of functionality” for your application.

When refactoring and optimizing your code, you may restructure your code without any risks, since all
your modifications are now verifiable. Unit tests ensure that there are no technical or functional
regressions and furthermore the coherence of behavior. They validate that your application will always
behave in the same way, if they are executed with success.
Additionally if you combine TDD with Extreme Programming (XP) and pair programming, you obtain
a code with a very high degree of quality.
Visual Studio 2012 externaltest framework support
The previous version Visual Studio 2010 already provides the possibility of using external test
frameworks. But unfortunately with multiple limitations such as:
 Dependency on third party applications for being able to execute unit tests. For example
Gallio needs Icarus Runner if you want to run your unit tests.
 Code coverage analysis does not work natively, only by using third party products (such as
NCover for example).
 Execution of unit tests is specific to certain plugins: for example there is a difference if you
run your MSTest unit tests from within Visual Studio 2008 or by using Resharper, which may
result in problems when trying to apply continuous integration processes.
As you can see, you have to multiply plugins and tools, that might not always be compatible with each
other, when using Visual Studio 2010 with external test frameworks. Really not an optimal situation,
when you want to benefit from specialized external test frameworks and their advanced functionalities!
One of the major updates of Visual Studio 2012 is the support of several external unit test frameworks
for multiple languages without any of the limitations mentioned above.
Here are some of the unit test frameworks that you can now use easily:
For .NET:
 NUnit (http://nunit.org)
 xUnit.net (http://xunit.codeplex.com)
 MBUnit (https://github.com/Gallio/Gallio-VS2011-Integration)
For Javascript/HTML:
 QUnit & Jasmine (http://chutzpah.codeplex.com)
For C++:
 MSTest Native (http://aka.ms/mstest-native-vs11)
How to use NUnit as external testunit framework
Lets see how to use NUnit as external test unit framework. First you have to install NUnit (currently as
Prerelease) via NuGet.

Then you have to install the test adapter plugin for NUnit (currently as Beta) via the Extension
Manager, which you can now find under “Tools/Extensions and Updates...”. Note that all test adapters
are free of charge and that the functionality to search and download those adapters is fully integrated in
Visual Studio 2012.

After installing the NUnit test adapter plugin, you are able to use all Visual Studio 2012 unit test
functionalities together with NUnit. You may for example execute your NUnit unit tests directly from
within the Visual Studio 2012 IDE, display the test results in the standard view “Test Explorer” and run
a code coverage analysis on your code.
Support for C++ in native MSTest
Another big feature of Visual Studio 2012 is that it now supports native MSTest unit tests for C++
applications. Good news for C++ developers, who may now also apply Test Driven Development using
native MSTest as unit test framework.

Following is an example implementation of a unit test in Visual C++ using the native MSTest unit test
framework:
Support for async and await in VS 2012 and its unit test framework
Windows 8 and .NET 4.5 introduce a major feature that will have a high impact on software
development as we know it: Asynchronous Programming. Visual Studio 2012 and its unit test
framework support this new approach perfectly. The async and await keywords, available in .NET 4.5,
may now be used for creating unit tests of asynchronous methods.
Lets say that you want to create a unit test for the following asynchronous example method:
The corresponding NUnit test method could be:
Managementof unit tests via TestExplorer
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.
PostBuild TestRuns
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.
TDD using Visual Studio 2012:A practicalexample
I am now 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, during the
implementation of a simple calculator example!
Phase 1: Write a unit test for a new functionality
Respecting the Test Driven Development approach, you have to create your unit tests before starting
with any implementations. In our example we have to write some unit tests for the methods “Addition”
and “Multiplication”. But first of all, we have to add a project of type “Unit Test Project” to our
solution (if you do not already have one).
You may now add the necessary unit tests. Here is an example of the unit tests you could add based on
the unit test framework NUnit:

Please note that the “Calculator” class and its methods “Addition” and “Multiplication” do not exist at
this stage yet.
Visual Studio 2012 provides the possibility to generate the missing code in an automatic way. For that
you just have to right-click on the “new Calculator” definition in the unit test project and choose to
generate the class via the “Generate/New Type” option in the menu.
A wizard opens and you are now able to configure multiple options such as the type (classe, struct,
interface, enum), the access (public, internal), the destination project and the file name for the
generation of the missing class.
The next step, after having auto-generated the “Calculator" class, consists of auto-generating the
missing methods within this class. This can be achieved in almost the same way as it was done for the
missing class. You do a right-click on the method calls “calculator.Addition(...)” and
“calculator.Multiplication(...)” in the unit test project and you generate them via the “Generate/Method
Stub” option in the menu.

Here is the auto-generated source code of those two methods:
In the last step of this phase you have to open the “Test Explorer” window where you may now execute
all your unit tests. This can be done by clicking on the “RunAll” button or by using the already
explained “Post Build Test Runs” option.
As expected your unit tests will fail, since the corresponding source code has not been implemented yet.
We will see how to do that in the next phase.
Phase 2: Implement the minimum code necessary to pass the test
Now in this phase, the only thing that needs to be done, is to implement the expected functionalities.
The idea is to develop the minimum code necessary, which responds to the functional requirements.
Everything that concerns optimization and amelioration must not be addressed since it will be treated
later in the next phase (refactoring).
Following the implementation you may now restart your unit tests by clicking on the “RunAll” button
or by using the already explained “Post Build Test Runs” option (see the previous blog post in the
series). Your should see that you unit tests have been terminated successfully. If this is not the case you
have to review your code and iterate until all of your unit tests pass successfully.

At this stage the source code corresponds exactly to the functional needs and it provides the expected
behavior. The final project structure includes a unit test project as well as an application
implementation project.
But the source code might not be optimized. Its quality might not adhere to your quality standards, so it
has to be ameliorate. The refactoring can be done without any problems since the unit test assure that
there are no regressions. Moreover, regressions can be detected very quickly and thus can be handled as
soon as possible. This is going to be explained in the next phase.
Phase 3: Refactor and optimize the source code
The process of improving your source code after the initial implementation phase (Phase 2) is called
“Refactoring”. The source code structure is modified internally without any modifications to the
external behavior (very important!!). A source code that just “works” is now transformed into a source
code that works in an optimal way. Most of the time, the resulting source code is executing with better
performance, using less memory and/or with a better software design.
The refactoring consists of the following steps (non-exhaustive list):
 Detect and eliminate all code duplication
 Limit complexity and the number of classes
 Simplify and optimize method algorithms
 Relocate, rename and harmonize methods

 Improve code readability
 Remove not used code (also called “dead code”)
 Add comments to complex code sections
In our simple example there is nothing to be refactored, since there are neither enough methods nor
enough classes. But this last step has to be done in bigger developments at the end of each cycle.
Afterwards, a new development cycle starts with new functionalities from Phase1 on.
ConclusionThe TestDriven Developmentwith Visual Studio 2012
As you have seen Visual Studio 2012 was greatly extended and enables efficient Test Driven
Development. It helps you on all steps and even enhances and optimizes your productivity.

Tutorial test driven development with Visual Studio 2012

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to Tutorial test driven development with Visual Studio 2012

Similar to Tutorial test driven development with Visual Studio 2012 (20)

Recently uploaded

Recently uploaded (20)

Tutorial test driven development with Visual Studio 2012