Dominic Hopton's Blog : Test Project

Tips & Tricks: Set the output type to EXE and give it a main method

dhopton — Tue, 25 May 2004 00:47:00 GMT

Ok, you’ve written your tests, and you want to debug them or you’ve got a test failing and you can’t quite see why. What are you gonna do? Well, right now we don’t have built in support for debugging of tests, but there is a sneaky workaround that I use a lot.

Because all our projects are just derivatives of the normal projects, you can set the same options. This means that you can turn the project into an EXE type rather than just a class library. Because it’s an EXE you can create a main method and allow F5 execution. Because the unit test framework works with any ol’ assembly you can still execute the tests from test view, even with a EXE rather than DLL.

One other sneaky trick I’ve thought about, but not gotten round to doing is setting mstest.exe as the command line for the debug session, and seeing if that would work. But As I say, I’ve not tried it yet – if It works, please share :)

UPDATE: Sorry, I should have made it clearer, this is a Tip for the May CTP - we're intending on adding full support for debugging tests, it's just it's not in there right now.

No! My Run config got toasted!

dhopton — Tue, 25 May 2004 00:46:00 GMT

Another problem with the run configuration is that the template runconfig (The one that gets added to new solutions) can easily become overwritten with your user one, thus potentially screwing up test execution for all projects AND new projects. This only happens in a specific situation, but sadly this is a very common situation.

So, what happens? Well, when you create a new Test Project (not Empty Test project) you are prompted in the wizard to add a default run config to the solution. If you select this option the run config is added to the solution, and you’re good to go. The only problem here is the bug that adds the run config as a link rather than copying to the solution directory. Because of this, all changes to the run config made in this situation will result in those changes being reflected across ALL solutions that were created in the same way, and ALL new projects where you add a run config in any manner to the solution.

You can work around this simply by not using the wizard to add a run config to the solution, and instead letting the Run Config Dialog add the run config when you first run a test.

When you first go to execute tests when there is no run config associated with the solution, the dialog will not list anything in the “Run Configuration” Drop down – this is fine. Click the browse button, and select localtestrun.rcg. Click Open, then click OK. When prompted “Do you want to add this to the solution” select Yes, and all will go fine and dandy. If the file is not listed, navigate to %ProgramFiles%\Microsoft Visual Studio 8\Enterprise Developer Tools\Testing Tools\TestProjectCommon\Templates\RunConfig\1033 and the file should be located there.

If you manage to corrupt your localtestrun.rcg that resides in the project directory, you can just copy it off the install media again and you’ll be up and running again. This can be found in the %ProgramFiles%\Microsoft Visual Studio 8\Enterprise Developer Tools\Testing Tools\TestProjectCommon\Templates\RunConfig\1033 directory on the media – just copy this to the same path on the hard disk.

I turned off code coverage and I can’t run my tests anymore!

dhopton — Tue, 25 May 2004 00:43:00 GMT

This is a problem we only found out after we’d sent off the DVDs to be pressed, and turns out to easy to repro, but also easy to workaround. It’s also got a slightly strange workflow compared to the way we think a lot of people will be using run configs initially.

If you enable code coverage and then subsequently disable it – all through the Edit Run Configuration dialog (or opening & saving from the Run test run config dialog), you will possibly find that when you run your tests you will see that the test result is error/fail and the message is “FileNotFoundException” or “MethodNotFound”.

How can you workaround this problem and get back to running your unit tests? Well, there are two ways:

a) Copy the localtestrun.rcg from the product directory over the one in your solution

b) Edit the .rcg file for your solution so that the XML element isNewLocalDeployment is set to false rather than true.

If you do either of these you will need to close your solution and re-open it to see the changes.

There is a simple way to avoid this happening. When working with run configuration, don’t use the “Edit Run Configuration” button on the toolbar to enable/disable code coverage. This is because using this dialog saves the changes to disk when you click OK & keep the changes. When you change settings in the Run Configuration dialog shown when you execute tests, the changes are only saved if you explicitly save them. Because of this subtle difference, you can change settings at runtime without screwing anything up.

Another option of source is to save the code coverage enabled runconfig to a separate file and just swap between them when you need to have or not have code coverage information.

One last thing on this topic – you may have a problem with a) because of another bug, which I’ll cover in another blogsicle.