Jason Zander is Corporate Vice President of Development for the Windows Azure team at Microsoft.
Learn more about Jason.
More videos »
Developers who are passionate about unit testing will often tell you why their favorite framework is the best. With Visual Studio 11, we wanted to give people a top-notch, developer-focused experience that let them use whatever framework they wanted. To add a unit testing framework to your development environment, just install the plugin from the Visual Studio Extension Manager (pictured below) or the Visual Studio Gallery online.
There are many test framework plugins available at this point, including:
And of course we still have the built-in test “MS-Test” framework for .NET code, as well as a new framework for C++ code.
Let’s take a look at the example of NUnit. The NUnit team shipped an adapter for Visual Studio 11 Beta on the same day the beta was released and just recently released an update with some important bug fixes. Getting started is as easy as installing the NUnit Test Adapter for Visual Studio 11 Beta here.
In this example, I’m using a test project, which is a .NET Class Library with a reference to NUnit.Framework.dll. Here’s a quick NUnit test to show how this works.
Then click “Run All” in the Unit Test Explorer window and see the results.
This ability to use different third party unit testing frameworks, and even to mix them within a single solution, was a major ask from our customers over the years. Now you can easily extend your experience to let your team use the unit testing engine they prefer.
As you’re writing tests and code, and running the tests in-between each step, you may find it gets a bit tedious to constantly switch back and forth. In Visual Studio 11, you can now configure the Test Explorer to automatically run unit tests after each successful build. This is a real time-saver because it makes the test run feel like it’s part of the build.
Thinking about your unit tests as part of the build is a natural thing. For a long time, teams have used continuous integration servers to build and run tests for every check-in. Now you can get that same outcome on your local machine.
To turn it on, just toggle the “Run Tests After Build” option in the Test Explorer toolbar.
The nice thing about this feature is that it lets you focus on the code and not on the other tool windows in Visual Studio. Only when things fail do you stop to look around and see what happened.
When a test fails, there are a few ways to figure out what went wrong. First, you can check the test runner, which provides rich exception information. In cases when that’s not enough, it can be useful to view the test with the debugger. With Visual Studio 11, you can debug NUnit tests the same way you debug other managed tests. To do this, simply right click on the test in the Test Explorer and choose “Debug Selected Tests”.
There are a number of analytics you may want to perform on your unit tests, and the most common one people use is code coverage. We significantly simplified the experience around collecting code coverage information for your unit tests, and enabled it to work with your 3rd party unit test projects. As pictured below, let’s select “Analyze Code Coverage” in the Test Explorer.
Now when the run completes, it will open the Visual Studio Code Coverage Results window, and display editor highlighting so I can easily determine where more test coverage may be required.
You can also easily check the coverage for a test (or a set of tests) by right clicking on what you want to analyze and selecting “Analyze Code Coverage”. This can be very handy when adding tests to existing code. The in-editor coverage coloring let you see exactly what parts of your code were run by the tests you selected.
As you can see, the QUnit tests are discovered and executed in the same experience as other unit tests. The extensibility of VS 11 unit testing makes supporting additional unit test framework like QUnit as simple as getting (or writing) an appropriate plugin that supports that system.
As mentioned earlier, we also have the ability in Visual Studio 11 to do native unit testing, with a new C++ unit testing framework shipping in the box. We’re really happy to enable this support for our C++ developers, so you no longer need to use the “/clr” flag or fall back to 3rd party frameworks.
Here’s a quick example:
For a full-fledged sample application, I recommend checking out the Hilo project, by the Patterns & Practices team, which now includes native C++ unit tests.
To learn more about native unit testing in Visual Studio 11, please visit MSDN.
In this post, we reviewed a range of new improvements for unit testing. These came about by the team focusing on a couple of key customer goals:
1. Flexibility – Use whatever test framework your team prefers
2. Simplicity & Consistency – Get a simple, consistent experience that lets developers focus on their work
I hope you will have an opportunity to try out the new Visual Studio 11 unit testing features. For more information, please visit MSDN.
Follow me at twitter.com/jlzander.