TestDriven.NET by Jamie Cansdale

TestDriven.Net 2.11: Parameterized NUnit Tests

TestDriven.Net has always supported parameterized test methods when used with the MbUnit testing framework. When using MbUnit, it is common for a single test method to execute multiple tests with different parameter inputs. The most famous of these test types is the MbUnit RowTest.

Until now there has been little reason to add support for executing parameterized tests using NUnit (historically NUnit has only supported parameterless test methods). However Andreas Schlapsi has recently written an implementation of MbUnit's RowTest using NUnit 2.4's Addin extensibility mechanism.

I've updated TestDriven.Net 2.11 to better support NUnit add-ins and enable the targeting of RowTests and other parameterized test types. This version also includes a workaround for a log4net related issue that was causing a noticeable delay when launching the NUnit 2.4 GUI. You can find the release notes for TestDriven.Net 2.11 here.

To install the RowTest Extension for NUnit you will need to do the following:

1. Download and install TestDriven.Net 2.11.
2. Download the RowTest Extension for NUnit 2.4.5 (Binary).
3. Create a directory called 'addins' in '%ProgramFiles%\TestDriven.NET 2.0\NUnit\2.4'.
4. Copy the 'NUnitExtension.RowTest.AddIn.dll' file into the 'addins' directory (don't put any non-assembly files there).
5. Add a reference to 'NUnitExtension.RowTest.dll' from your NUnit test project.

You can then start writing and executing MbUnit style RowTests inside your NUnit projects! You can find Peli's original RowTest example here.

To view your RowTests inside the NUnit GUI you will need to use 'Test With > NUnit 2.4'. You will find this option on the 'Solution Explorer' project context menu.

Thanks to Wayne Brantley for letting me know about the RowTest Extension for NUnit.

TestDriven.Net 2.10: 'Go To Reflector' now supports generics

Over the past year the 'Go To Reflector' command has become a first class citizen inside TestDriven.Net. You will find the 'Go To Reflector' button on many different context menus inside Visual Studio. The ones I use most often during development are the 'Code Context' and 'Project Reference' menus. When I'm debugging I tend to use the 'Call Stack' and 'Modules' context menus.

For a long time I've put off attempting to add support for generics to the 'Go To Reflector' command. The Visual Studio CodeModel and StackFrames APIs don't really support generics, so I wasn't even sure if this would be possible. This was becoming a problem with more and more code being written that uses generics. I decided it was time to bite the bullet and see what could be done.

I'm happy to say that TestDriven.Net 2.10 now has pretty decent support for generics.

You can 'Go To Reflector' from your generic class definitions. Generic methods, classes, fields, properties and nested classes are all supported.

You can round trip and 'Go To Source Code' from inside Reflector. I often find using Reflector is the fastest way to navigate my own code.

When you're debugging you can 'Go To Reflector' from any stack frame in the 'Call Stack' window. This is particularly useful when the debugging option 'Just My Code' is turned off. When an exception is thrown you can quickly see what caused it by selecting the top of the call stack.

Note: For updated 'Go To Reflector' on 'Call Stack' support you will need to be using TestDriven.NET 2.10.2173 or later (I released this a few days after the original 2.10 build). You can read the release notes and download the latest version from here.

TestDriven.Net 2.10: Smart Build

There are a number of new features in TestDriven.Net 2.10 that I want to highlight (apart from the VS 2008 crash workaround). The one I'm going to focus on here is subtle, but significant I believe - especially for people working with large solutions.

Smart build is a new optimization that allows you to skip the build step before test execution when there are no source code changes. Anyone working on a solution with a large number of projects will know how time consuming the build can be before any tests can be executed. Somewhat surprisingly this remains true even when no actual source code edits have been made and nothing needs to be compiled. I've had reports of the build check taking as long as 45 seconds before any tests could be executed! (Thanks to Brian Genisio in particular for bringing this to my attention)

The new smart build feature overcomes this particular problem by monitoring your solution for source code edits and automatically skipping the build step if there is nothing new to compile. This can significantly improve performance when running multiple tests in the same solution. For example there is now no penalty for choosing to execute all tests in a fixture after an individual test starts to pass: a common usage pattern.

I will elaborate further on other new features in future posts. In the meantime you can read the latest release notes and download TestDriven.Net 2.10 from here. If you find any issues, please don't hesitate to contact me.