TestDriven.NET by Jamie Cansdale

TestDriven.NET FAQ List

I have started populating a FAQ list for TestDriven.NET.  Here is one just in from Alex Hildyard.

Q: After installing TestDriven.NET under XP Professional, Windows Firewall flags incoming connection warnings on attempting to run tests in VS. However, the add-in seems to operate correctly even if I disallow it internet access. Any ideas on what's causing this?

A: TestDriven.NET uses remoting over a TCP channel to communicate with the test process. This is what the Windows Firewall is detecting. Because is uses the localhost/127.0.0.1 loopback interface, it doesn't in fact require Internet access.

Unknown Test Runner Type

[Update: Fixed in build 799]

A few people have reported experiencing 'Unknown test runner type'. When they try to execute a test. I have narrowed it down to what looks like a shadow copying issue. It has me completely baffled though, because shadow copying isn't enabled! It only seems to happen on a few machines. I haven't been able to reproduce it here on any of my configurations.

As far as I know shaddow copying will happen in the following situations; an assembly exists in the GAC, an assembly is downloaded from a remote location or shadow copying is enabled in the app domain. Can anyone think of a reason why an assembly would be copied to "...\local settings\application data\assembly\dl2\dl4lt40e.2po\5p2ozohz.6nm\52f69477\00d3c97f_01b7c401\testdriven.testrunner.dll", if none of these were true?  Also why would this shadow copying happen on some machines but not others?

If you are experiencing this issue, please comment here and let me know what software configuration you're using. I am particularly interested to know what version(s) of .NET and Visual Studio you have installed. Thanks to Gary McCullough I do have a workaround. Please leave an email address so I can sent it to you (your email address won't be visible on the web!).

GMail Drive Shell Extension

Very very cool, but will it scale?  Will this be the death of GMail?

TestDriven.NET RC2: Keyboard Mapping

Peter Provost - If the focus is on the Output window, and you use a hotkey to launch the addin, you get an output message that says, "Unknown window vsWindowTypeOutput". It sure would be nice if it could find the topmost open editor and use the first test class in there.

In this latest release I have imporved the way TestDriven.NET chooses a set of tests the execute. If the code editor window is selected, the test(s) to execute will be determined by the position of the caret. All test(s) in a method, class or namespace can be executed this way. If any other window is selected, the active item will determine the test(s) to run. The active item is the project or project item most recently selected (these items are shown in solution explorer with grey backgrounds). This is basically as Peter suggested.

You can now right click on project items in solution explorer and select run tests(s). This is a quick way to execute tests without opening the source document. The type at the top of the document will be executed as a test fixture. Classes with a 'Main' method rather than a [TestFixture] attribute will be executed as an ad-hoc test.

The TestDriven.NET command names have also changed. They now all start with 'TestDriven.NET.' followed by the short command name. Here are the commands that are most likely to be of interest.

• Client - Build and execute test(s) in a cached external process (this is the default 'Run Test(s)' test runner).
• Solution - Build and execute all tests in the current solution.
• Restart - Restart the last executed test(s).
• Debugger - Build and execute test(s) in the debugger.
• DebugString - Build and execute test(s) showing all OutputDebugStrings (including in spawned app domains and processes).
• DllLoad - Build and execute test(s) showing all Dlls as they load.
• CreateProcess - Build and execute test(s) showing all spawned process and command lines.
• DTE - Build and execute test(s) in the Visual Studio process (the extensibility object is accessible using (DTE)AppDomain.CurrentDomain.GetData("DTE")).
• Abort - Abort the current test run.
• NUnit_GUI - Build and load tests using the NUnit GUI (in an external process).

You will find these fixes in TestDriven.NET RC2

TestDriven.NET RC2: Test With... Debugger

Kevin Driedger - When debugging a Test using NUA it recompiles the whole solution not just the projects that the test is dependant on. Currently I am working around this problem by adding a configuration in the solution that only includes the dependant projects. Unfortunately, vs.net takes a quite a while to switch profiles.

When TestDriven.NET executes a test, it first builds the test project and any dependencies. It then executes the test using the chosen test runner (in this case the debugger). Unfortunately when executing with the debugger attached, Visual Studio defaults to building all projects in the solution. This was causing a full build to be done after the partial (project and dependencies) build.

I'm now delegating build responsibilities to the project runner when executing with debugger. This means the test project will only be built once. Unfortunately Visual Studio still defaults to doing a full build (which can be very slow on large solutions). In Visual Studio 2003 and 2005 where is an option to, "Only build startup projects and dependencies on Run". I have a couple of screen grabs showing where to find this under 'Test With... Debugger' on the QuickStart.

You will find this fix in TestDriven.NET RC2

TestDriven.NET RC2

The final release is getting close. This last two weeks I've been fixing bugs and tackling issues I kept putting off. A lot a work has gone into getting the installer right. Getting an add-in to install and uninstall consistently for all versions of Visual Studio .NET is a minefield!

You can download TestDriven.NET RC2 here.  Have look through the QuickStart if you haven't already.

I'll write about what's new tomorrow. There is a nice supprise for people running as non-admin.  You can install as a regular user!

Introducing MutantBuild

I'm now using MSBuild and WiX for all of my active projects. I ended up with a few VS2003 solutions that I didn't want to convert to VS2005/MSBuild format for one reason or another. It is a pain keeping Windows Forms applications compatable with .NET 1.x when editing using VS2005. I also wanted to be able to compile NUnit for .NET 1.0 using the VS2003 solution strait out of SourceForge.

I kept meaning to post about compiling for .NET 1.x using MSBuild. I had everything working on my machine, but getting everything into the right place was a little involved. I've ended up writing an installer that collects together all the files you need along with the required modifications.

You can find the installer and documentation here.

Using it is very straightforward. Say you wanted to compile a VS2003 (or VS2005/MSBuild) solution for .NET 1.0.  After installing MutantBuild, execute the following from the command line...

> mutantbuild @debug(1.0).response your.sln

FTP Uploads and WinXP SP2

For some strange reason FTP uploads are only working from one machine on my network.  The working machine is running WinXP SP1.  All of the other machines are WinXP SP2 or Windows 2003 Server.  I've disabled the windows firewall on all of these machines (I'm running behing a NAT router) but still no joy.

The transfers are running in PASV mode.  I've tried it from IE, the command line FTP.EXE and SmartFTP.  I am completely at a loss now.  I just want to get my build server uploading files.  Can anyone help?

Update: If you downloaded anything other than TestDriven.NET 0.9.670 RC1 you may have been hit by this problem. The build script uploaded a couple of truncated versions.

Haacked: I don't have ZoneAlarm, Black Ice or the SP2 personal firewall running. It is still a mystery why it isn't working.

Update: It gets even stranger still. I'm behind an ADSL/NAT/Firewall so of cause I leave IE in the default FTP PASV mode. Here is how it was set before.

Out of desparation I uncheck the box and take it out of PASV mode. As much as anything this was to see what alternative (if any) error is gave me. Suddently FTP starts working!  I don't know how it can possibly get through a NAT router when not in PASV mode.  Any thoughts?