TestDriven.NET by Jamie Cansdale

Too many times I've found myself adding and removing Console output to my tests. I've added it when I need more information about how an individual test is running. I've removed it when cleaning up the output from running all tests in an assembly. I've found what I think is an effective solution.

I've recently changed NUnitAddin so that it runs unit tests in an external process. It controls and communicates with this process using .NET remoting. Because tests are run in an external process it's possible to attach the VS.NET debugger set breakpoints on them. When I manually attach the CLR debugger (as follows) it works great.

I've started working on a guide to using the addin.  All there is so far is a number of screenshots.  You can tell pretty much how it all works just from them.

Have you ever wondered how to enumerate all AppDomains in the current process?  It can be done with a little COM interop...

The aim of the project is to make Test a first class citizen inside Visual Studio.NET. Test should be as integrated and natural a part of your development environment as Build is today. Wherever you find a Build action you could also expect to find a Test action. For example there is an action to Run Tests in a Project or Solution. There is also an action to Run Test(s) on the code context menu. Which tests are run depend on whether you click inside a Test, TestFixture or Namespace. Obviously this doesn't correspond to Build (until we get Edit & Continue that is ;). The corresponding Build action will be performed before any tests are run (Test depends on Build).