TestDriven.NET by Jamie Cansdale

Chris Szurgot has informed me that Trace Monitor is back online. This application monitors debug output from all running applications. If you're testing things running in multiple processes it is indispensable. You can find it here along with source and some of Chris's other projects. If you don't already use this application, I would be interested to know what you use as an alternative.  Also drop me a line if you would like the add-in version...  ;o)

If anyone has tried using the Reflector Add-In with the latest version of Reflector, they will have found that the automatic download isn't working.  Reflector's download location and public key changed recently causing it to break.  I'm sorry I haven't released an update sooner.  I've been rather distracted with a complete rewrite of the Managed Add-Ins framework.  At some point you can expect a leaner, meaner add-in machine.  For the moment I've got a fixed version of the Reflector Add-In for you (plus source).  Unfortunately something in Reflector has changed causing it to stop working inside VS.NET 2002 (I imagine most people are using 2003 now anyway).  If you have any idea what the problem is please let me know!

I didn't know you could do this...

I've just stumbled on the GotDotNet blog list.  You'll find a whole screen full of interesting looking blogs there.  I must have been too engrosed in Chris Brumme's epic posts to ever think about clicking in the top right hand corner.  The very first blog is dedicated to the pretty much undocumented Fusion assembly loader.  It looks like I've got some catching up to do!

I have finally got round to trying NUnit 2.1 with NUnit Add-In. I am relieved to report that it works out of the box with the current version of NUnit Add-In (the one you’re probably using). All you have to do is start using the ‘NUnit.Framework’ assembly from the 2.1 release. If you’re interested to see the code that binds to pretty much any version of NUnit, you can find it here. There’s obviously some reflection in there, but the more interesting bit is the RealProxy. I had to use that to deal with the evolving test listener interface. The reason I started using 2.1 was for the TestFixtureSetUp/TearDown attributes. I didn’t particularly want to be firing up new instance of Visual Studio for every little add-in unit test. With the new attributes I can do the set-up and the start of the test run and tear-down at the end. This goes for whether I’m running an individual test or all tests in an assembly. Here is an example of how to use the new attributes, plus some other stuff for fun.. ;o)

namespace Tests
{
 using System;
 using System.IO;
 using System.Diagnostics;
 using System.Runtime.InteropServices;
 using NUnit.Framework;
 using EnvDTE;

 [TestFixture]
 public class TestVisualStudio
 {
  [TestFixtureSetUp]
  public void TestFixtureSetUp()
  {
   _dte = new DTEClass();
   _dte.MainWindow.Top = 50;
   _dte.MainWindow.Left = 50;
   _dte.MainWindow.Height = 200;
   _dte.MainWindow.Width = 1024;
  }
  private DTE _dte;

  [TestFixtureTearDown]
  public void TestFixtureTearDown()
  {
   _dte.Quit();
   Marshal.ReleaseComObject(_dte);
  }

  [Test]
  public void TestNUnitAddInEscapes()
  {
   Debug.WriteLine(_dte, "_com");
   Debug.WriteLine("=====================");
   Debug.WriteLine(_dte, "_verbose");
  }

  [Test]
  public void TestShowMeTheCode()
  {
   _dte.MainWindow.Visible = true;
   System.Diagnostics.StackFrame frame = new System.Diagnostics.StackFrame(0, true);
   string fileName = frame.GetFileName();
   int lineNumber = frame.GetFileLineNumber() - 1;  // make it zero based
   string[] lines = new StreamReader(fileName).ReadToEnd().Split(new char[] {'\n'});
   string code = lines[lineNumber];
   Debug.WriteLine(code);
   _dte.StatusBar.Text = code;
   System.Threading.Thread.Sleep(5000);
   _dte.MainWindow.Visible = false;
  }
 }
}

In a previous entry I posted some code that would run unit tests after every successful build. I used ‘Register for COM Interop’ and a ‘ComRegisterFunction’ attribute. Ian Griffiths asks, “What does this add that you don't get with VS.NET 2003's build events?” You can think of this as running lower level build events. Instead of executing a batch file and passing it an assembly location, you’re executing a method and passing it a Type object. It also means you can create logic that will run as part of installation. If these unit tests don’t pass, then fail early and don’t even install!

I'm afraid the download location and public key of Reflector has changed in this latest version, meaning the automatic download and update feature of Reflector Add-In won’t work. I'll write a note here as soon as there’s an updated version available.

I have just realised that VS.NET has everything in place to support a build and test policy without the use of any external add-ins! You can define and enforce your unit tests in code on a per project basis. This technique uses the little known ‘ComRegisterFunction’ attribute and ‘Register for COM interop’. If this method returns an exception then the build fails. A new app domain is created per build with a base directory of ‘bin\Debug’.