Debugging ASP.NET Unit Tests on Classes in App_Code

Posted by Dave Bouwman | Posted in ASP.NET, Team System, Unit Testing | Posted on 27-03-2007

0

As if the title of the post is not painful enough, I thought I’d just whip up a quick post for others who have run into issues with getting debugging of ASP.NET unit tests working for classes in App_Code.

Just a quick note – ordinarily I’d create a separate assembly, but part
of this code is working with the ProfileCommon class, which is created
on the fly by ASP.NET based on settings in web.config, and as far as I
could find, you can’t access this class outside of an ASP.NET web app.

So – I’ve created myself some classes and had Visual Studio cook up some unit tests for me. I jumped in there and added some legit code, and went to run the test and… I was not getting an error per se – the break points were simply not being hit. In the border of the code, there was a small icon as shown below…

Mousing over this, I got the highly informative message: “The breakpoint will not currently be hit. No symbols have been loaded for this document”. So the obvious thing you’re thinking is that I need to attach the debugger to the ASP.NET Worker process. Anyhow, that’s what some intensive Googling revealed.

The MSDN guidelines on setting up debugging of ASP.NET Unit Tests is here. And while it is conceptually correct, the only issue is that my version of Visual Studio 2005 (Team Edition) does not have “Attach to Process” on the debug menu (not sure why) . Which led to this article which notes that it may also found at “Tools –> Attach to Process”. Armed with this, I was able to make some headway…

Here are the abridged steps:

  1. Write some classes in App_Code that you want to test
  2. Create a test project, and have it generate the tests – this is critical as it will build private accessors for you.
  3. Attach the VS debugger to aspnet_wp (XP) or w3wp.exe (Windows Svr 2003)
  4. Then run your test from the Test View (Test –> Windows –> Test Viewer)

Even like this, it’s not exactly bomb-proof. I need to re-attach a lot, and start/stop standard debugging of the site occasionally. All the more reason to put your business logic in another assembly if at all possible!

Comments are closed.