Subscribe: TestDriven.NET by Jamie Cansdale
Added By: Feedage Forager Feedage Grade B rated
Language: English
bit  net  nunit  studio  support  test runner  test  testdriven net  testdriven  tests  version  visual studio  visual 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: TestDriven.NET by Jamie Cansdale

TestDriven.NET by Jamie Cansdale

Zero Friction Unit Testing for Visual Studio .NET


TestDriven.Net 3.0 – All Systems Go

Wed, 09 Jun 2010 14:37:07 GMT

I’m pleased to announce that TestDriven.Net 3.0 is now available. Finally! I know many of you will already be using the Beta and RC versions, but if you look at the release notes you’ll see there’s been many refinements since then, so I highly recommend you install the RTM version. Here is a quick summary of a few new features: Visual Studio 2010 supports targeting multiple versions of the .NET framework (multi-targeting). This means you can easily upgrade your Visual Studio 2005/2008 solutions without necessarily converting them to use .NET 4.0. TestDriven.Net will execute your tests using the .NET version your test project is targeting (see ‘Properties > Application > Target framework’). There is now first class support for MSTest when using Visual Studio 2008 & 2010. Previous versions of TestDriven.Net had support for a limited number of MSTest attributes. This version supports virtually all MSTest unit testing related attributes, including support for deployment item and data driven test attributes. You should also find this test runner is quick. ;) There is a new ‘Go To Test/Code’ command on the code context menu. You can think of this as Ctrl-Tab for test driven developers; it will quickly flip back and forth between your tests and code under test. I recommend assigning a keyboard shortcut to the ‘TestDriven.NET.GoToTestOrCode’ command. NCover can now be used for code coverage on .NET 4.0. This is only officially supported since NCover 3.2 (your mileage may vary if you’re using the 1.5.8 version). Rather than clutter the ‘Output’ window, ignored or skipped tests will be placed on the ‘Task List’. You can double-click on these items to navigate to the offending test (or assign a keyboard shortcut to ‘View.NextTask’). If you’re using a Team, Premium or Ultimate edition of Visual Studio 2005-2010, a new ‘Test With > Performance’ command will be available. This command will perform instrumented performance profiling on your target code. A particular focus of this version has been to make it more keyboard friendly. Here’s a list of commands you will probably want to assign keyboard shortcuts to: Name Default What I use TestDriven.NET.RunTests Run tests in context   Alt + T TestDriven.NET.RerunTests Repeat test run   Alt + R TestDriven.NET.GoToTestOrCode Flip between tests and code   Alt + G TestDriven.NET.Debugger Run tests with debugger   Alt + D View.Output Show the ‘Output’ window Ctrl+ Alt + O   Edit.BreakLine Edit code in stack trace Enter   View.NextError Jump to next failed test Ctrl + Shift + F12   View.NextTask Jump to next skipped test   Alt + S   By default the ‘Output’ window will automatically activate when there is test output or a failed test (this is an option). The cursor will be positioned on the stack trace of the last failed test, ready for you to hit ‘Enter’ to jump to the fail point or ‘Esc’ to return to your source (assuming your ‘Output’ window is set to auto-hide).  If your ‘Output’ window isn’t set to auto-hide, you’ll need to hit ‘Ctrl + Alt + O’ then ‘Enter’. Alternatively you can use ‘Ctrl + Shift + F12’ (View.NextError) to navigate between all failed tests.   For more frequent updates or to give feedback, you can find me on twitter here. I hope you enjoy this version. Let me know how you get on. :)[...]

TestDriven.Net 2.24: XCopy Deployable Test Runners

Thu, 05 Nov 2009 16:56:04 GMT

There is a new feature in TestDriven.Net 2.24 (and 3.0 Alpha) that should greatly simplify the deployment and versioning of test runner plug-ins. In previous versions it was important that a compatible test runner plug-in was installed for each test framework you use.

This was manageable if all of your projects used the same version of a test framework – however it could quickly get out of hand if a project referenced a different framework version. Because it isn’t always feasible to upgrade all test projects at the same time, teams could end up trapped using an old version of a test framework or with unit test projects that are difficult to run.

As of TesDriven.Net 2.24, it is now possible to include the test runner alongside its test framework assembly. The advantage of doing this, is your tests can be executed without any installer dependencies! For example, you could use any version of xUnit, MbUnit or NUnit and your teammates would be able to execute the tests without needing to worry about which version of xUnit or Gallio to install!

This feature is enabled using a file with a .tdnet extension, which lives in the same directory as your referenced test framework assembly (e.g. ‘mbunit.dll’, ‘xunit.dll’, ‘nunit.framework.dll’ etc.). If you’re using Gallio 3.1 or 1.5, you will find the required ‘MbUnit.dll.tdnet’ or ‘xunit.dll.tdnet’ file already exists. For earlier versions of Gallio, xUnit or MbUnit – this feature can be enabled by crating a simple XML file.

For example, say you have a test project that uses MbUnit 2. This test framework was released long before .tdnet files existed. To make the MbUnit test runner xcopy deployable, you would need to create a ‘MbUnit.Framework.dll.tdnet’ file and copy the contents of ‘\Program Files\MbUnit\bin’ into version control.

The ‘MbUnit.Framework.dll.tdnet’ looks like this:

       MbUnit {0}.{1}.{2}

The ‘MbUnit.Framework.dll.tdnet’ file should be placed alongside ‘MbUnit.Framework.dll’, ‘MbUnit.AddIn.dll’ and the rest of MbUnit 2. Once you have referenced the ‘MbUnit.Framework.dll’ assembly in this directory, you can uninstall MbUnit 2 and still use TestDriven.Net to execute your tests!

If you’re using a version of prior to 1.5, the ‘xunit.dll.tdnet’ file would look like this: {0}.{1} build {3}

If you need help making this work with any other test framework, please let me know and I’d be happy to post the details here.

I hope you enjoy the simplified deployment and versioning of whatever test runner you use!

You can download TestDriven.Net 2.24 & 3.0 Alpha from here.

TestDriven.Net 3.0 Alpha – Support for Visual Studio 2010 Beta 2

Tue, 27 Oct 2009 20:20:49 GMT

For the best part of a week, I’ve been battling with the Visual Studio 2010 Beta 2 extensibility model. I’m happy to report that - finally - I’ve managed to make it bend to my will. ;-)


At this point I’ve decided to fork TestDriven.Net 2.x and 3.x. Going forward, TestDriven.Net 3 will support Visual Studio 2010, 2008 & 2005. TestDriven.Net 2 will continue to support Visual Studio 2008, 2005 & 2003. They will be developed in parallel until the RTM versions of Visual Studio 2010 and TestDriven.Net 3.0 are released. I will then focus my energy on TestDriven.Net 3.x.

With TestDriven.Net 3.0 Alpha, you can expect the Visual Studio 2008 & 2005 support to be stable.

In order to support Visual Studio 2008 Beta 2, I’ve needed to do a number of pretty gruesome workarounds. One of these workarounds involves repainting TestDriven.Net’s command bar button icons each time Visual Studio starts (Beta 2 doesn’t persist them). All previous versions of TestDriven.Net have activated themselves on demand rather than on startup (when Visual Studio loads). This meant installing TestDriven.Net had no impact on Visual Studio startup times.

If you’re sensitive to Visual Studio startup times, it’s still possible to make TestDriven.Net activate on demand in Visual Studio 2010. Simply uncheck the ‘Startup’ box next to TestDriven.Net in the ‘Add-in Manager’. Be warned, however, that TestDriven.Net’s command bar buttons pictures will appear blank until the first time they’re used.


For the ‘Test With > Coverage’ functionality to work with .NET 4.0, you’ll need to install NCover 3.2 or higher (see here). You can also use ‘Test With > Team Coverage’ if you’re running Visual Studio 2010 Premium or higher.


You can download TestDriven.Net 3.0 Alpha from here.

Which test runner are you using ?

Tue, 18 Aug 2009 16:42:02 GMT

Fabio Maulo is doing a poll to find out which test runners people are using:


You can take the poll and see the results here.

TestDriven.Net 2.23 Beta – Cleaner Stack Traces

Fri, 14 Aug 2009 16:59:08 GMT

You have probably noticed with previous versions of TestDriven.Net, stack traces could turn into an unruly mess of file path information.


In TestDriven.Net 2.23, source file paths are displayed as relative to their containing project.


There are a few cases where using a project relative path would be ambiguous or a source file outside your solution is referenced; in these cases an absolute file path will be used. In general however, you should find that stack traces are much cleaner.

Here are links to download read the release notes for TestDriven.Net 2.23 Beta. Please contact me if you find any issues with this version.

TestDriven.Net 2.23 Beta – Faster!

Fri, 14 Aug 2009 12:01:15 GMT

If you’re using TestDriven.Net 2.23 on a 64-bit OS, you should find that running tests is almost twice as fast!

It turns out that the JIT compiler for x64 is considerably slower than for x86 (and uses more memory). You can easily improve the startup time for your EXE projects by changing them to compile for x86. In fact this is what Microsoft is doing in Visual Studio 2010 (the default for EXEs will be x86). It’s only worth compiling EXEs for AnyCPU if your application might use a lot of memory. See Rick Byers’ post on the subject: AnyCPU Exes are usually more trouble than they're worth.



For this reason the default for AnyCPU test projects is now to execute in a 32-bit (WOW) process. If you need to temporarily run tests in a 64-bit process, there’s an option to change the default.


If you have tests that check behavior in a 64-bit process, you can add them to a test project that compiles for the x64 platform.


Because this is a significant change, I thought it warranted its own post. There’s a lot more in this release that I’m planning to blog about later.

Here are the download and release notes for TestDriven.Net 2.23 Beta.

TestDriven.Net 2.22 RTM - What’s New?

Thu, 18 Jun 2009 14:19:00 GMT

I'm happy to report that TestDriven.NET 2.22 RTM has cleared the launch pad! It has been a while since the previous RTM version, so here is a quick recap of what’s new: NUnit 2.5 TestDriven.Net now includes the production release of NUnit 2.5. This is the recommended version of NUnit if you’re using .NET 2.0 or above. To ensure maximum compatibility with .NET 1.x and legacy NUnit extensions, the last releases of NUnit 2.2 & 2.4 are also included. (more here) 64-bit Windows By default TestDriven.Net will execute test projects compiled for AnyCPU in a 64-bit process. There are however some test runners that must run inside a 32-bit process. If you are testing with NCover 1.5, Team Coverage, dotTrace or .NET 1.1 (MSBee), TestDriven.Net will automatically fall back to using a 32-bit process. To force your tests to always execute in a 32-bit process, you can specify ‘Platform target: x86’ in your test project’s build properties. F# F# is now a first class citizen inside TestDriven.Net. To enable stack traces on failed assertions, you must specify ‘Other flags: --optimize+ notailcalls’ on your test project’s build properties. For best results use NUnit 2.5, MbUnit 3.0 or xUnit 1.1 (which all support test attributes on static methods). (more here) Options A new ‘TestDriven.Net’ options pane is available when using Visual Studio 2005 and above. This can be used to selectively include/exclude tests in specified categories, choose when to display trace/debug output and choose to use new test process for each test run (as a workaround for badly behaved tests). (more here) Visual Studio 2010 Beta1 Previous beta versions of TestDriven.Net were compatible with the PDC 2008 release of VS 2010, but not the VS 2010 Beta1 release.  To enable support for VS 2010 Beta1, you must do a ‘Complete’ install and assign keyboard shortcuts to the TestDriven.Net commands you wish to use.   (more here) Typemock Isolator TestDriven.Net now includes active support for Typemock Isolator. You can disable the Typemock Isolator add-in and leave TestDriven.Net to enable Isolator for test projects that require it. This can significantly improve performance when starting applications/web sites from Visual Studio and executing tests that don’t require Isolator. NCover This version of TestDriven.Net has been tuned to work with NCover 1.5.8 (included with TD.Net) and the commercial NCover 2.x & 3.x versions. When you ‘Test With > Coverage’, the contents of NCoverExplorer will be automatically refreshed and only classes with debug symbols will appear in the tree view. (more here) You can download the latest version from here. If you’re a professional software developer, perhaps your employer would be interested some Enterprise licenses. Feel free to point the appropriate person in your organization to the licensing & purchase page or contact us for a quote. :) I’m now going to start working on the next version in earnest. You are welcome to contact me with any suggestions you have for a future release. Thanks for your support, bug reports and interest![...]

TestDriven.Net 2.22: Support for Visual Studio 2010 Beta 1

Wed, 03 Jun 2009 17:55:12 GMT

I’ve just uploaded a new version of TestDriven.Net (2.22 RTM) which is compatible with Visual Studio 2010 Beta 1.

Unfortunately this support is somewhat limited because command bar extensibility has been disabled in VS 2010 Beta 1. All is not lost however because the commands still work when executed using a shortcut key. This is how many power users invoke TestDriven.Net already and can make for even less friction when executing your tests.

To enable support for VS 2010 Beta1 you will need to select ‘Complete’ when installing TestDriven.Net. (Support for VS 2010 currently disabled when doing a ‘Typical’ install.)


You can use the ‘Environment > Keyboard’ pane on the ‘Options…’ dialog to assign new shortcut keys. To list all of TestDriven.Net’s commands, simply: “Show commands containing: testdriven”.

You will probably want to assign shortcuts for the following commands:

TestDriven.NET.RunTests: Run Test(s)
TestDriven.NET.Debugger: Test With > Debugger
TestDriven.NET.RerunTests: Repeat Test Run
TestDriven.NET.Reflector: Go To Reflector
TestDriven.NET.ApplicationNUnit25: Test With > NUnit 2.5 (start the NUnit GUI)


Alternatively I’ve created a .vssettings file you can import using ‘Tools > Import and Export Settings…’.

The keyboard assignments are as follows:

Alt+T: Run Test(s)
Alt+R: Repeat Test Run
Alt+D: Test With Debugger
Alt+E: Go To Reflector
Alt+N: Launch NUnit 2.5
Alt+V: Test Inside VS
Alt+B: Build Current Project

Once imported I’m using Alt+T to execute an ‘Ad hoc’ test from inside the ‘go’ method.


You can download TestDriven.Net 2.22 RTM from here.

TestDriven.Net 2.21: Now includes NUnit 2.5 RC

Thu, 30 Apr 2009 16:05:29 GMT

Support for NUnit 2.5 RC A couple of days ago, Charlie Poole announced that the first NUnit 2.5 release candidate is now uploaded. I’ve hurried to get a new version of TestDriven.Net with support for this version ready. I’m happy to announce that TestDriven.Net 2.21 Beta (which includes NUnit 2.5 RC) is now available for download. This is a major NUnit release with lots of new features. Here is the list that was posted on the NUnit mailing list: Parameterized (data-driven) tests are supported, with features similar to those found in mbUnit and Theories - as used in JUnit- are supported fully, including support for Assume.That. New attributes allow the specifying the thread and apartment state requirements of a test. Exception handling can now be moved into the test code using Assert.Throws or the Throws.Exception syntax. Test methods and fixtures may now be generic and many asserts and constraint expressions now support generic syntax. Many constraints now permit substitution of a user-defined comparison algorithm through the Using modifier. Lambda expressions are supported. Test execution may now take place in a separate process for better isolation. Tests may be loaded and executed using a selected runtime version. Tests, setup methods, teardown methods and data sources may be static if desired. If there are no instance methods, then NUnit doesn't need to construct your test class. Source code is displayed in the gui, where available. Charlie has also posted a top 10 reasons try NUnit 2.5. Improved x86 / 32-bit support on a 64-bit OS This version also contains improved support for running tests in a 32-bit process. To configure a test project for 32-bit execution, simply select ‘x86’ as the ‘Platform target’ in the project properties. After doing this, the ‘Run Test(s)’ and ‘Test With > NUnit 2.5’ commands will execute your tests in a 32-bit process (this doesn’t work for NUnit 2.4). By default projects configured for ‘Any CPU’ will execute tests in a 64-bit process (unless you’re testing with NCover, Team Coverage or dotTrace).    Experimental Visual Studio 2010 support TestDriven.Net was working with the Visual Studio 2010 PDC CTP version. Unfortunately I’ve had less luck with more recent pre-Beta versions (Visual Studio was crashing). You can try the experimental support by choosing ‘Custom’ setup and enabling the ‘Visual Studio 2010’ feature. There is a chance this will be working again when the Visual Studio 2010 Beta is released. Trace/debug messages now appear in ‘Debug’ pane When stepping through code started from TestDriven.Net, you may have noticed that trace/debug messages appeared in the ‘Test’ pane but not the ‘Debug’ pane. Trace/debug diagnostic messages will only appear in the ‘Test’ pane when targeting specific tests, but not when executing all tests in a project / solution. Release Notes & Download Here are links to the TestDriven.Net release notes and download. Don’t hesitate to contact me or the NUnit team if you find any issues with this release.[...]

TestDriven.Net 2.20: Improved NCover Integration

Tue, 21 Apr 2009 15:01:54 GMT

In the latest release of TestDriven.Net, you’ll find much improved integration with all versions of NCover:

Support for 64-bit Windows

‘Test With > Coverage’ now works on 64-bit versions of Windows. In previous versions this could be made to work by compiling your test project for x86. The new version will automatically execute your tests in a 32-bit process if a 64-bit version of NCover can’t be found. (There is similar 64-bit Windows support for dotTrace and Team Coverage)

No more ‘Reload coverage file?’ dialog

NCoverExplorer 2.1 & 3.0 will no longer prompt to reload the coverage file. The coverage report will automatically refresh when new data is available. If you’re using NCover 3.0.18 or higher, you won’t be prompted to save a ‘New Project’ when you close NCoverExplorer.

Automatic assembly filtering

If you’re using NCover 3.0, only assemblies that have a corresponding PDB file will appear in the ‘Explorer’ window. I’m hoping this is a good alternative to explicitly naming assemblies that shouldn’t appear in the coverage support.

Support for Typemock Isolator

You can now execute ‘Test With > Coverage’ with NCover 3.0 and Typemock Isolator installed. (Previous versions would fail with the error: ‘Couldn't find TypeMock profiler name for NCover 3.0’.)

Recommended Versions of NCover & Typemock

If you have a commercial license for NCover, make sure you’re using NCover 3.0.18 or later. If you’re using Typemock Isolator, I recommend you use at least version 5.3.0.


If you’d like more timely updates on new releases, you can find me on twitter here. 3.0 RTM

Sat, 07 Mar 2009 11:11:19 GMT

Congratulations Kzu on the release of Moq 3.0 RTM!

You can get it here (I love the domain name).

There’s a fascinating back and forth between Ayende and Daniel (kzu) where they discuss different ways to use mock frameworks. Ayende (who developed Rhino Mocks) is more in favor of interaction testing than Daniel who is a state/classic TDDer.

Recently I’ve been trying to separate my tests into unit tests, interaction tests and integration tests. For interaction testing I’ve been using Typemock Isolator, which allows me to break a few runes in order to exercise some hard to test code. Moq is looking very interesting as a mock framework to use with my traditional unit tests.

TestDriven.Net 2.19: Release Notes

Mon, 09 Feb 2009 17:10:21 GMT

Which Test Runner?

The latest version of TestDriven.Net will display the name of the test runner used in the test results summary. If the target project doesn’t reference a known test framework assembly, TestDriven.Net will use the ‘Ad hoc’ test runner to quickly execute the target method.


You can see the above method has been executed using the ‘Ad hoc’ test runner. If this happens when targeting real unit test, the chances are a test runner to handle the target test type or version hasn’t been registered.

NUnit 2.5 Beta 2 Support

This version includes support for NUnit 2.5 Beta 2. The previous version had a bug that caused tests that threw an exception to show as skipped rather than failed.

Test With > .NET 1.1 on a 64-bit OS

If the .NET 1.1 SDK is installed and you’re using Visual Studio 2005, you will have the option to ‘Test With > .NET 1.1’. Under the covers this functionality builds your project using MSBee before executing your tests using .NET 1.1. This will now work when executed on a 64-bit OS.

I’d be interested to hear if there’s any demand for this feature on Visual Studio 2008.

Visual Studio 2003 Support

This version once again works on Visual Studio 2003. Only one person noticed this was broken on the previous beta. Are there many projects still being developed using Visual Studio 2003? I’m using MSBee for all my legacy .NET 1.1 support.

Running xUnit tests on a 64-bit OS

Some people have been experiencing problems registering the xUnit test runner on a 64-bit OS. It turns out the problem was due to xUnit sometimes registering itself under HKLM and sometimes under HKCU depending on what was previously installed. If you’re experiencing this problem, try re-registering xUnit (using xunit.installer.exe) after installing this version.

Clear Error List Before Build

Failed tests will now be removed from the error list when a new build starts. This prevents failed tests from becoming mixed up with build errors. I think this is the correct default behavior.


You can find the release notes here and download here.

Improved support for MbUnit, xUnit and Gallio

Wed, 03 Dec 2008 19:58:42 GMT

The main focus of the TestDriven.Net 2.18 release has been to improve support for test runner plug-ins in general (not just NUnit). If you’re using xUnit, MbUnit or Gallio – I recommend you upgrade to this version. Automatic support for 64-bit machines The registry layout on 64-bit machines is plain weird and full of pitfalls for the unwary. The registry layout is different depending on whether you’re installing under HKLM or HKCU. Under ‘HKLM’ the ‘SOFTWARE’ key is split and test runner plug-ins needed to be registered twice in order to work in both 32 and 64-bit processes. There is no such split under ‘HKCU’ and plug-ins installed there only needed to be registered once. This created the unfortunate situation where plug-ins installed for ‘all users’ wouldn’t work when running in a 64-bit process, but plug-ins installed ‘just for me’ would work fine. Rather than expect plug-in developers to deal with this weirdness, I’ve made some changes to automatically support plug-ins that aren’t 64-bit aware. If you have an assembly that needs to work on 32 and 64-bit machines, you may find the following snippet useful: public static RegistryKey OpenSoftwareKey(bool hklm, string name) { string fullName = @"SOFTWARE"; if (hklm) { if (Marshal.SizeOf(typeof(IntPtr)) == 8) { fullName += @"\Wow6432Node"; } return Registry.LocalMachine.OpenSubKey(fullName + @"\" + name); } return Registry.CurrentUser.OpenSubKey(fullName + @"\" + name); } The following ad-hoc test will display TestDriven.Net’s install directory (assuming TestDriven.Net is installed ‘for all users’): void test() { using(var key = OpenSoftwareKey(true, @"MutantDesign\TestDriven.NET")) { Console.WriteLine(key.GetValue("InstallDir")); } } Better support for ah-hoc tests In previous versions of TestDriven.Net, a test runner plug-in was required to explicitly signal when none of its tests were found for execution. This would give other test runners (such as the ad-hoc test runner) a chance to handle the test. Unfortunately most test runners have been signaling a successful test run when tests were found but none were targeted. I’ve changed it so the ad-hoc test runner will automatically get a chance to execute if no tests were executed and the test runner plug-in indicated a successful test run. The upshot of this is that you can now have ad-hoc side-by-side with MbUnit or xUnit tests. If you’re using xUnit, try doing ‘Run Test(s)’ on each of the following methods: [Fact] public void TestMe() { Console.WriteLine("Console output isn't displayed when using xUnit"); Assert.True(false, "Comment out [Fact] and run as ad-hoc test! ;)"); } void hello() { Trace.WriteLine("Hello, World!"); } void dump() { Trace.WriteLine(AppDomain.CurrentDomain, "_verbose"); } (ad-hoc tests should work side-by-side with all other test framework methods as well) Improved performance when executing with Gallio / MbUnit v3 Gallio is a test runner that supports many different test types (MbUnit, xUnit, NUnit, MSTest and more). It has its own plug-in architecture and it doesn’t use the default TestDriven.Net app domain test isolation. This makes Gallio very flexible, but it also meant it wasn’t appropriate to setup and tear down the Gallio engine for each test run. I’ve made some changes to allow Gallio to stay resident in the test process. This has significantly improved performance (esp[...]

TestDriven.Net Options Pane

Wed, 03 Dec 2008 12:26:03 GMT


In the latest version of TestDriven.Net you will find a new options pane. The options are as follows:

Hide trace/debug output when running all tests in project/solution

In the past this setting has always been hardwired to true. It means you can add trace information to a test without cluttering up the ‘Test’ output pane when all tests are executed. An alternative way to ensure a message will always appear in the output is to use ‘Console.WriteLine’ rather than ‘Trace.WriteLine’. This also means the verbose Gallio/MbUnit test run output will show up when executing all tests in a project.

Cache test process between test runs

By default the external test process will be cached when the ‘Run Test(s)’ command is used. This process appears in the tool tray as a rocket icon which can be used to kill the process. This is fine unless one of your tests starts leaking leaking native resources (such as leaving open a file handle). The best solution is to fix the resource leak, but you now have to option to work around the issue by killing the test process at the end of each test run. This can be useful if the resource leak is in a 3rd party DLL which can’t be easily be changed.


This option supports the most common use of test categories; you can choose to include or exclude a selection of categories. This is useful if you want to exclude long running tests or if your machine isn’t configured to execute integration tests. This feature is currently only supported by the NUnit runner that comes with TestDriven.Net, but I believe it will be supported by a a future version of Gallio.

You can specify your NUnit test categories like this:

    [Test, Category("LongRunning")]
    public void LongRunning()

There are lots of features in TestDriven.Net that could be exposed as options. I’ll try to resist this temptation as much as possible, but I’m sure a few more will creep in. ;-)

TestDriven.NET 2.18 + NUnit 2.5 Beta

Tue, 02 Dec 2008 22:15:17 GMT

I’ve just uploaded a new version of TestDriven.Net with support for NUnit 2.5 Beta. There’s a menagerie of weird and wonderful new attributes to choose from in this point release of NUnit. Ben Hall has written a good summary of the Alpha version and I’m sure Charlie Poole will be blogging about the Beta in the coming days. Here’s a quick summary of a few new attributes: Generic test fixtures can be used when you need to run a batch of tests against few different implementations of a type. In the past something similar could be achieved by having an abstract base fixture and extending it for each implementation you needed to test. By using a generic fixture you keep all your test code in a single class and I think it’s more expressive. [TestFixture(typeof(ArrayList))] [TestFixture(typeof(List))] public class IListTests where TList : IList, new() { [Test] public void Count() { IList list = new TList { 1, 2, 3 }; Assert.AreEqual(3, list.Count); } } The ‘TestCase’ attribute is similar to MbUnit’s ‘RowTest’. With this attribute you transform a single test method into multiple test cases. You can also define an expected return result, but I’d advise against using this if you want a stack trace when your test fails. It’s better to explicitly define the assert inside the test method. public class TestCases { [TestCase(4, 2, 2)] [TestCase(2, 1, 1)] [TestCase(5, 2, 3)] public void Add(int answer, int a, int b) { Assert.AreEqual(answer, a + b); } } In previous versions of NUnit you could specify which threading model your tests required by adding some XML to your test project’s App.config file. You can now specify this directly on the test that needs it using the RequiresMTA/STA attributes. [Test, RequiresMTA] public void MTA() { Assert.AreEqual(ApartmentState.MTA, Thread.CurrentThread.ApartmentState); } [Test, RequiresSTA] public void STA() { Assert.AreEqual(ApartmentState.STA, Thread.CurrentThread.ApartmentState); } Lastly the ‘TestFixture’ attribute is no longer required and test methods are allowed to be static. This means NUnit can now be used in a natural way for testing F# code. Note, you will need to have "Other Flags" set to "--optimize+ notailcalls" in your project’s build properties if you want to see a stack trace on any failed asserts. #light open NUnit.Framework [] let fsharp() = Assert.AreEqual(2 + 2, 4) Update: I’ve tried to highlight a few features in NUnit 2.5 which can be used to make your unit tests clearer. Xerxes Battiwalla has written a post about Assert.Throws() which also falls into this category. [Test] public void CreateDomain_Null() { Assert.Throws(() => AppDomain.CreateDomain(null)); } For more information see the TestDriven.Net 2.18 release notes and the NUnit 2.5 documentation.[...]

Microsoft F# and TestDriven.Net 2.16

Fri, 10 Oct 2008 10:42:22 GMT

Now that F# is being officially productized, I thought it was time to make it a first class citizen inside TestDriven.Net.

When learning a new language I like to experiment by writing ad-hoc tests and viewing my code inside .NET Reflector. My initial focus has been getting 'Go To Reflector' and the targeting of parameterless methods and properties working.

You can get the latest release of F#, including the compiler, tools, and Visual Studio 2008 integration from the F# Developer Center. You will also need TestDriven.Net 2.16 or above.

The F# team has put together a collection of F# sample code. The samples come with their own 'F# Micro Samples Explorer' application, but they are also ideal for running as ad-hoc tests. In particular have a look at the 'beginners.fs' and 'intermediate.fs' modules in the 'Samples101' project.


To view the code using .NET Reflector, simply right click inside a method, property, module or project and 'Go To Reflector'.


At the moment only parameterless methods and properties are supported. This is due to the way F# makes extensive use of type inferencing for parameters. Luckily it is parameterless methods and properties that it makes most sense to target for evaluation or running as unit tests. I'll talk more about unit testing F# code in a future post.


Hello, F#!

Thu, 09 Oct 2008 17:41:33 GMT


This is a quick post to break my writers block.


Silverlight NUnit Projects

Thu, 01 May 2008 19:34:24 GMT

I've been doing some experiments to find out if it's possible to execute NUnit on a Silverlight project. I knew that Visual Studio 2008 and Expression Blend both host Silverlight for use in the designer window. It turns out that rather than host a separate instance of the CoreCLR, the designer simply loads the Silverlight assemblies into the host runtime. This simplifies the business of creating a compatible unit testing framework considerably!

With a little bit twiddling, I've managed to tweak the 'nunit.framework' assembly so that it's compatible with Silverlight projects. In order for your tests to execute successfully, you also need to ensure that all Silverlight assemblies (except 'mscorlib') are set to 'Copy Local: True'. After this is done you can run, debug and even do code coverage on your Silverlight unit tests!

Because creating one of these projects is a fiddle to set up, I've created Silverlight NUnit Project template that does the work for you. To install the template simply open the 'SilverlightNUnitProject.vsi' file and ignore the unsigned content warning. Once installed, you will find it under the 'Visual C# / Silverlight' section of the 'New Project' dialog. You can download the template from here.


To execute one or more unit tests you should use 'Run Test(s)' rather than 'Test With > Silverlight'.


In summary you now have 3 options when testing Silverlight projects.

  1. For unit testing you can create a Silverlight NUnit Project and use the usual TestDriven.Net commands.
  2. For integration testing (within the context of a browser) you can use the Silverlight Testing Framework.
  3. For spelunking individual methods inside the CoreCLR you can use 'Test With > Silverlight'.

I'd be interested to hear how you get on.

TestDriven.Net 2.13: Support for NUnit 2.4.7

Mon, 28 Apr 2008 14:01:36 GMT

The latest release of TestDriven.Net is now compiled against NUnit 2.4.7. This version of NUnit includes Andreas Schlapsi's popular RowTest extension. The RowTest attributes have been moved to the 'nunit.framework.extensions' assembly (which you can find here: \Program Files\TestDriven.NET 2.0\NUnit\2.4\nunit.core.extensions.dll).

Here is an example RowTest method that tests a prime number function:


The prime number function might look like this:


As you can see the intention of the test is very clear and there is no repetition. I've written more about parameterized unit tests here.

TestDriven.Net 2.13: Support for Silverlight 2.0 Beta 1

Thu, 24 Apr 2008 23:44:00 GMT

I've just uploaded a new version of TestDriven.Net with support for Silverlight 2.0 Beta 1. Microsoft have certainly kept me on my toes as there have been lots of changes since Silverlight 1.1. I'm sorry it has taken a while!

At the moment you're limited to running individual public methods (ad-hoc tests). If you need to run a suite of tests I recommend you use this in conjunction with the Silverlight Testing Framework that was released at MIX. Jeff Wilcox has posted a detailed tutorial that shows how to use the framework here. When running your tests using 'Test With > Silverlight', bear in mind that you're simply executing the test method and any test attributes (TestInitialize etc.) will be ignored.


I've also included an application called 'agx.exe' that lets you run console applications using the Silverlight/CoreCLR from the command line. After you've installed TestDriven.Net you will find this standalone application here: \Program Files\TestDriven.NET 2.0\agx.exe. This is simply an application that I use for my own testing purposes that I thought other people might find useful.


You can download the new version of TestDriven.Net from here.