TestDriven.NET by Jamie Cansdale

NCover on Visual Studio .NET 2002/2003?

Matt Ellis wrote:

Hi Jamie - this looks really neat, but how can it work with all versions of Visual Studio if it requires .net 2?

Visual Studio will load the .net runtime for it's own packages, and I'd expect that runtime to be the version the IDE targets, and since you can't have multiple instances of the runtime loaded in one exe, how can this require .net 2?

Just wondering, 'cos I'd love to use this in 2003, but in a work environment, where we we're not yet ready to migrate to 2005 and .net 2.0.

This functionality does work with Visual Studio .NET 2002/2003. I know this is rather counterintuitive and sure to become a FAQ.

There are two components that make up NCover. One part is written in C++ (native code) and executes inside the target .NET process. This component is compatible with .NET 1.0, 1.1 and 2.0. The other component executes outside the target process and is responsible for monitoring it and writing the XML coverage file. For a number of reasons Peter Waldschmidt chose to write this component (NCover.Console.exe) using .NET 2.0. This is why NCover support has a dependency .NET 2.0, but is still able to create coverage reports for .NET 1.0/1.1 processes.

In order to put to rest the idea that TestDriven.NET 2.0 is only compatible with Visual Studio 2005, I've created a video showing it working with Visual Studio .NET 2002/.NET 1.0. In the video you can see TestDriven.NET being used to test a .NET 1.0 application using NCover, NCoverExplorer and NUnit GUI.

You may be wondering why I think it's important to stay compatible with VS2002. In the survey I put up last year, more than 6% of users said they still use VS2002! More importantly however is confidence. If I were to drop support for VS2002 now, who's to say I wouldn't drop support for VS2003 in a years time? I know for some users this confidence is important.

Test With... Coverage

Last week I announced that TestDriven.NET now has code coverage integration for users of Visual Studio 2005 Team Suite, Developer or Tester. This week I'm happy to announce a solution for all other Visual Studio users! I've now added support for the popular code coverage tool NCover. Peter Waldschmidt the author of NCover has been working with me in order to get the two applications playing nicely together.

When I told to Grant Drake that I had NCover support working, he mentioned that he had written an NCover report viewer called NCoverExplorer. I quickly realized that NCoverExplorer would be an ideal viewer to use with TestDriven.NET. Compared to the default XSL summary transform that comes with NCover, the NCoverExplorer application is lightning fast. There is a tree view that lets you drill down and see your code colorized according to the coverage report. You can find out more and see what NCoverExplorer looks like here.

For the moment NCoverExplorer is bundled with TestDriven.NET. It is likely that at some point it will migrate into the NCover project.

As I mentioned before, TestDriven.NET's NCover support is compatible with all versions of Visual Studio. It does however have the following dependencies:

• NCover 1.5.1 Beta (or later)
• Microsoft .NET 2.0

If you have any suggestions for NCoverExplorer, be sure to let Grant know.

TestDriven.NET Users Group

I've created a new Google Group for TestDriven.NET Users. You can subscribe to it using email, rss or the web. If you have a question that others would benefit seeing the answer to - please ask it here. If you have any hints and tips for using TestDriven.NET, please contribute them here! I hope this will be the start of a more active user community. I look forward to seeing your posts...

TestDriven.NET + Visual Studio Test Tools

TestDriven.NET 2.0 Beta includes support for the Visual Studio Test Tools (VSTT) unit testing framework that comes with Visual Studio 2005 Team Suite, Developer and Tester. If you are using this unit testing framework you will probably find TestDriven.NET a faster and more convenient way to execute your unit tests (if you're not convinced, I recommend you read Brian Button's article). As well as being able to execute your unit tests using TestDriven.NET, you can also view them using the NUnit GUI (when launched from the 'Solution Explorer' context menu). This is achieved using a special adaptor that knows how to handle a subset of the VSTT attributes and functionality.

At the moment the following attributes and classes are supported:

TestClassAttribute
ClassInitializeAttribute
ClassCleanupAttribute

TestMethodAttribute
TestInitializeAttribute
TestCleanupAttribute

IgnoreAttribute
TimeoutAttribute
ExpectedExceptionAttribute

TestContext

The most glaring omission is support for AssemblyInitializeAttribute and AssemblyCleanupAttribute. I'm interested to know if there are any other VSTT unit testing attributes that people are using and would like to see supported. If there are, please let me know and I'll do my best to make them work.

In order for the VSTT support to work, the 'Microsoft.VisualStudio.QualityTools.UnitTestFramework' and 'Microsoft.VisualStudio.QualityTools.Resource' assemblies must be available. You can find them installed in the GAC with Visual Studio 2005 Team editions. They are however not redistributable, so if you want to use them on a non-Team version of Visual Studio you should check the licence agreement first!

TestDriven Macros for Keyboard Junkies

I've had a number of people email asking where the run all tests in solution command has gone. This command disappeared when I did some refactoring to unify the various 'Run Test(s)' commands. I actually did this to make TestDriven.NET more keyboard friendly. The idea was to make the 'Run Test(s)' command do the right thing depending on context. For example if the code window isn't active, it will execute tests in the highlighted 'Solution Explorer' item. For example if the 'Output' window is active, it will execute tests in the currently active source file. This only works if the 'Track Active Item in Solution Explorer' option is checked (I believe this is no longer the default setting in Visual Studio 2005).

Knowing how the 'Run Test(s)' command works, it is easy to write a macro that emulated the old run all tests in solution functionality. I've created a macro project here, that you can load using 'Load Macro Project...' in the 'Macro Explorer' tool window. Once loaded you will find a new 'Macros.TestDriven.RunTests.Solution' command that you can assign a shortcut key or add a tool bar button.

There a second command in the macro project that can be used to execute tests in a specific project item. This might come in useful if you've repeatedly running a subset of tests in the solution you're working on. When you download the macro you will find this command hard coded to run 'money\money\MoneyTest.cs' (i.e. solution 'money', project 'money' and project item 'MoneyTest.cs'). You can change this to target any solution, solution folder, project, project folder or project item you like. Note it will only execute the first test fixture in a given project item and assumes that a project folder has a corresponding namespace.

Official NUnit Release

I have just uploaded a version of TestDriven.NET that was built against the latest official NUnit release (2.2.6). From now on I'll only be using official NUnit releases rather than doing continuous integration using the latest NUnit source in CVS. There was some method to my madness when I started doing continuous integration with the NUnit source. However now the NUnit feature I needed is part of the official release, there is no longer an imperative to stay on the bleeding edge. This should make for more stable releases and fewer surprises for Charlie Poole and the NUnit team.

Got it Covered?

I have recently added a feature that allows the code coverage support built into Visual Studio 2005 Team Suite, Developer or Tester to be accessed using TestDriven.NET. Simply use the new 'Test With... Coverage' button you will find on most of TestDriven.NET's context menus. This will execute a subset of your unit tests with code coverage enabled. You can use it with NUnit, VSTT (Visual Studio Team Test), MbUnit, Ad-Hoc or any other supported test type.

I have created a video showing code coverage being used on the 'Money' unit testing sample that comes with NUnit. As you will probably notice I'm pretty new to using code coverage on unit tests. My instinct when working with the sample was to comment out and make failing tests for any of the un-covered code. I'd be interested to hear from anyone who has successfully incorporated the use of code coverage into their "Red, Green, Refactor" routine.

Code Coverage support is the first of many features that will be included in a commercial TestDriven.NET Team Edition. This however won't be the death of FREE versions of TestDriven.NET. Expect more news in the next day or two.

You can find the latest build here or on FolderShare.

P.S. Let me know if there any other code coverage tools you would like to see supported.

Performance Improvements

If you have a test assembly with a lot of unit tests, you should see some pretty dramatic performance improvements with the latest build. I have to thank Grant Drake, from some excellent feedback and repros.

It turns out that the Assembly.GetName() method is very slow. I had a quick go using the Ants Profiler and could see the problem almost immediately. It looks like there may be some uncached assembly resolving going on during the call to Assembly.GetName(). I should have taken the fact that it's a method rather than a property as a hint that it might be slow.