TestDriven.NET by Jamie Cansdale

Zero Friction Unit Testing for Visual Studio .NET

  • Field of Dreams

    This last few days I have started getting back into MSBuild. At the end of last year I was colaborating with Loren Halvorson trying to make MSBuild part of our respective build processes. The idea was to carry on using Visual Studio .NET 2003, but to convert solution and project files to MSBuild before compiling. At the time the build files (.targets) that came with the PDC version of VS 2005 didn't support embedded resources, the MSBuild engine took a lot of coaxing to work with .NET 1.1 and there was no easy way to build C++ projects.  In the end it all turned out to be a little too painful.  Loren went on to use the NAnt <solution> task (which has matured a lot) and I went back to doing Visual Studio command line builds (the only way at the time to build C++ project files).

    This last attempt turned out to be a lot more successful.  I have been able to develop using VS 2005, build using MSBuild (and .NET 1.0), package using WiX and deploy on everything from VS 2002 and up!  You can find the end results here.

  • VS 2005 beta 1

    It has been a bit of work getting it to work with VS 2005 beta 1. In this latest revision the Visual Studio extensability assemblies have changed. Also the technique I was using to activate the add-in in a new app domain no longer works. I've now fixed it to use the default domain but this causes issues for VS2002. I can no longer use binding redirects in the app domain's config file to make it work with .NET 1.0. I am now forced to build against .NET 1.0 if I want to remain compatable with VS 2002.  Luckily MSBuild has come to the rescue!

  • System.Testing

    Peter Provost has started a petition to include unit testing support in all versions of Visual Studio 2005.  While I agree that unit testing should be essential part of all development, I don't think Visual Studio is the place to introduce an important new API.  I think a much more fitting place would be the BCL and SSCLI/Rotor.  At the moment the BCL has an extensive set of unit tests.  I would be in favor of converting these over to using a core testing framework (say 'System.Testing').  We would then have a standard API for writing tests under all implementations of the CLI.  I think this is where real value would come.