TestDriven.NET by Jamie Cansdale

Code Coverage Tips

I thought I'd share a couple of code coverage FAQs.

1. How do I merge the code coverage results from multiple test projects?
2. I'm using VS2005 Team Suite/Developer/Tester -- is it possible to use NCover/NCoverExplorer?

To merge the code coverage results from multiple test projects, you need to select all of the test projects you want to execute. You can do this by holding down 'Ctrl' and selecting the projects in the 'Solution Explorer' window. Once you've done this you can 'Test With... Coverage' and all of the test run results will be merged. This technique works with NCoverExplorer and Team Coverage.

By default the coverage test runner will use Team Coverage if a Team version of Visual Studio 2005 is being used. If Team Coverage isn't available it will request the user to install Peter Waldschmidt's NCover. It will then use Grant Drake's NCoverExplorer for coverage visualisation. It is testament to what a fantastic job Peter and Grant have done that so many people have asked to use NCover/NCoverExplorer - even when they're using a VS2005 Team edition!

At the moment to make this possible you will need to tweak TestDriven.NET's .config file, which you can find here:
%ProgramFiles%\TestDriven.NET 2.0\TestDriven.dll.config

You need to change the typeName of the 'Coverage' testRunner to be NCoverCoverageTestRunner instead of CoverageTestRunner.

It would also be possible to have two menu items -- 'Test With... NCover' and 'Test With... Team Coverage'. I will however leave this as an exercise for the reader. ;-) Hint, the other coverage test runner type is called 'TeamCoverageTestRunner'.

TestDriven.Net Users Geo Map

I have recently started using Google Analytics and am pleased to discover what a cosmopolitan lot TestDriven.Net users are. Here is a plot of the last 500 visitors. The largest clusters are in Beijing, Tokyo, London, Paris and Moscow.

Ingo Lundberg from Sweden recently contacted me about a bug where failed tests where not double clickable or showing up on the task list. This turned out to be caused by a new feature in .NET 2.0. In .NET 2.0 stack traces are translated into the local language. For example in Sweedish a test run might look like this:

------ Test started: Assembly: Test.dll ------

TestCase 'Test.TenPotHandlerTests.qwe' failed:
      vid Test.TenPotHandlerTests.qwe() i C:\src\dotNet\Test\TenPotHandlerTests.cs:rad 29

0 passed, 1 failed, 0 skipped, took 0,67 seconds.

Did you notice the Swedish text "vid" (== at) and "rad" (== line) in the output? I'm curious to know how TestDriven.Net is working for users in China, Russia and Japan. If you're reading this from one of those locations, I would grateful if you could get in touch. You can find my contact details here.

ClassLibrary Projects and App.config

In Visual Studio .NET 2003 if you want you unit tests to use an app config file you need to ensure a config file exists with the same path as your test assembly but ending with '.config'. Life has improved a bit with Visual Studio 2005 as it will automatically copy any 'App.config' file to the correct place even for ClassLibrary projects. You can achieve the same affect in VS2003 by using the following post-build event:

copy "$(ProjectDir)App.config" "$(TargetPath).config"

Security Apps Break .NET 2.0 Remoting

The problem manifests itself as a crash whenever a .NET Remoting TcpChannel is closed. It isn't the application that closes the channel that crashes, but the application at the other end. In the case of TestDriven.Net it depends which functionality you're using which end crashes. If you use 'Test With... Debugger' then Visual Studio 2005 will crash. If you use 'Run Test(s)' then the test process (ProcessInvoker.exe) will crash when Visual Studio exits.

To repro the issue with NOD32 do the following:

1. Install .NET 2.0
2. Download RemotingSamples.zip
3. Make sure NOD32 IMON module is running
4. Run RemotingServer.exe
5. Run RemotingClient.exe

At this point the RemotingServer.exe application will exit with a "needs to close" dialog and the following exception:

Unhandled Exception: System.AccessViolationException: Attempted to read or write
 protected memory. This is often an indication that other memory is corrupt.
  at System.Net.UnsafeNclNativeMethods.OSSOCK.WSAGetOverlappedResult(SafeCloseS
ocket socketHandle, IntPtr overlapped, UInt32& bytesTransferred, Boolean wait, I
ntPtr ignored)
  at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32
 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
  at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32
errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

I would really like to get to the bottom of this. It is by far the most serious issue reported by TestDriven.Net users. My guess it that is isn't the fault of these applications, but they are all using a common DLL. I would like to find out what the issue it and it there's a patch. Thanks to Paul Welter for the repro and everyone on the TestDriven.Net Users group for reporting it.

Update 1: Manuel Rohrhirs wrote to let me know that Broadcom Advanced Control Suite which is installed by Dell also causes this issue. This situation is getting out of control. The seem to be a lot of applications that are being installed by default that will break any application that uses .NET 2.0 Remoting!

Update 2: It looks like James Woodall hit exactly the same issue with NetLimiter.

ASP.NET 2.0 Web Sites and Project Dependencies

I have had the occasional report that TestDriven.Net doesn't always build project dependencies. Until recently I hadn't been about to consistently repro this. It now seems the issue is related to having an ASP.NET 2.0 Web Site as part of a solution. For some reason as soon as a web site is added to a solution the dependency checking breaks down. This even happens even with unrelated projects that were working fine before.

I now have what seems to be an effective workaround. Instead of using the 'SolutionBuild' Visual Studio automation object, I'm now directly invoking the build command. If you would like to help test the workaround, please drop me an email.

Running TestDriven.Net on Vista

I haven't had a chance to install Vista yet, but Reggie has. If you're having trouble getting TestDriven.Net to run on Vista, you may like to read this post. The thing you need to remember is that by default TestDriven.Net installs for the current user (this allows for Limited User installations). If you change to an Administrator account to do the installation then make sure you install for "all users". If you install as a Limited User then TestDriven.Net will be installed in the 'Documents and Settings\User Name\Application Data' directory rather than 'Program Files'.