58BITS
58BITS

Debugging Unit Tests in Visual Studio 2008 and ASP.Net

Submitted on May 31, 2008, 4:31 a.m.

Visual Studio 2008 Professional shipped with the Visual Studio 2008 Team System unit test framework (which in Visual Studio 2005 was not available in the Professional version).

The test system is pretty cool - with excellent test code generating options and wizards. One really interesting feature is the ability to create tests for ASP.Net projects (file based, or application based). The tests created will be decorated as follows:

 

Previously to the only way to test components in an ASP.Net application - especially one that depended on any custom configuration settings or configuration sections in the Web.config file - was to take a copy of all the required settings - and place them in an App.config file for your Unit Test project. Then using a test running framework like TestDriven.Net  or NUnit - run the tests.

With the new Visual Studio 2008 test suite, you can simply use the Test Wizard to create the test, which will detect all the dependencies and create test methods that look like the one above. When run - the tests execute in the same processes as the referenced web application (and so use the same configuration settings).

If you want to debug your tests - you then have to attach the debugger to the either the development web server, or the IIS process that is hosting your local website.

Here's a link to an article that will show you how to do either - How to: Debug while Running a Test in an ASP.NET Solution .

However you have to re-attach the debugger to the process manually for every test run you want to debug, which is a drag. After googling for a while - I wasn't able to find an easy way to get F5 debugging that would automatically attach to the correct process (a command line option in the project maybe?). Still, the essence of the tests are to test assertions against your code and expected results so for a mature application test suite this isn't too big a problem. However for a TDD design approach - having to re-attach the debugger on each run is pretty inconvenient. Am I missing something?