February 2003 - Posts

Debugging Tests

If anyone has been having difficulty with the 'Debug Tests' functionality, there's a much more stable version up with build 92.  Go to the 'Tools' menu and 'Debug Tests'.  This will start a new test process with the debugger attached.  You can then set breakpoints, run tests and even compile new tests (which feels strange with the debugger still attached).  You won't be able to compile if the process has stopped on a breakpoint (the files will be locked).  It's not quite Edit & Continue, but if feels pretty close.  Let me know if you have any problems.

I can't get over how effective Ad Hoc tests have turned out to be.  Being able to jump into any method is such a boon (even if you're not unit testing).  Never again will I create a console application do a quick experiment.  Now I just write a method and jump in there!  Give it a try - I promise you won't be disappointed... ;)

Stopping on Failed Assertions

After reading the following entry in Dejan's weblog, I decided to see it if what he suggests is possible using NUnitAddin.

Unit Testing Frameworks [Dejan's Weblog]

Something strikes me as extremely wrong with all these unit testing frameworks that are popping up all over the place: they all provide an indication of how many tests have passed and failed. Huh? What's the purpose of that? When a unit test fails, I want the test execution to immediately stop in the debugger at the offending line so that I can see where the problem is. To do anything else is a lack of good sense.

Goto 'Exceptions...' on the 'Debug' menu. Select 'Common Language Runtime Exceptions' and 'Add...'. Add a new exception called 'NUnit.Framework.AssertionException'. Select 'When exception is thrown: Break into the debugger'. The debugger is now configured to stop on failed assertions. Next goto 'Debug Tests' on the 'Tools' menu. A new test process should launch with the debugger attached. You're now ready to start running tests (individual or all in project/solution). When an assertion fails, the following dialog should appear...

Posted by Jamie Cansdale | 4 comment(s)
Filed under:

G: is for GAC

From Jeff Key's .net blog
Using Explorer to get to physical files in the GAC

The Explorer extension the framework installs to view the GAC in %windir%\assembly doesn't let you do much with those files. If you try to access the physical folders below the assembly folder, you are redirected to the assembly folder. If you want to get at those files (and if you do, be careful), simply subst a drive to the %windir%\assembly\gac folder.

For example, if I want my GAC files to be represented by drive letter G, I simply enter the following:

subst g: %windir%\assembly\gac

Now open Explorer, go to drive G: and you're all set.

This is such a good trick I've added it as batch file with a link in my startup directory (where has autoexec.bat gone btw?).  Using this trick it seems you can easily add assemblies from the GAC using the VS.NET add references dialog.  The great thing about assemblies in the GAC is they're guaranteed not to move.  You can even flip to compiling against the Rotor (and Mono?) GAC by remapping G: to the relevant directory.  Okay, where's the catch?  I get the impression you aren't supposed to do this.
Posted by Jamie Cansdale | 6 comment(s)
Filed under:

Switching Target Frameworks with VS.NET 2003

I can't believe I missed this neat feature of VS.NET 2003. There goes my reason for staying with the old version.  2003 here I come...

With Visual Studio .NET 2003 you can
easily switch the target Framework version:
this will generate a .config file for you.



For .config files:
 
http://www.gotdotnet.com/team/changeinfo/

--
Thomas Scheidegger - MVP .NET - 'NETMaster'
http://www.cetus-links.org/oo_dotnet.html - http://dnetmaster.net/

Posted by Jamie Cansdale | 1 comment(s)
Filed under:

Spelunking with Ad Hoc Tests

Here's a screenshot showing how easy it is to start spelunking about using Ad Hoc tests.  In the example below I've defined a class that creates and disposes of an app domain.  All the Ad Hoc test does is return the AppDomain object (which dumps all of its fields and properties).  If an Ad Hoc test method is static - the constructor and dispose methods won't be called.  Ad Hoc test methods can be private (you won't have to modify your code).  At the moment methods with parameters aren't supported.  A future version may pop up a dialog box for the parameters.

If you want to dump an object's fields and properties from inside a test you can do the following (using a category of '_verbose' with Trace/Debug)...

Trace.WriteLine(ob, "_verbose");

Immediate - Ad Hoc Tests

Okay, as promised I've implemented Ad Hoc tests in the latest build. The idea is to allow any method to be used as an Ad Hoc test. If the class the method belongs to implements a constructor or the IDisposable interface, these will be used to set up and tear down the test (unless the method is static). If the method returns an object, its fields and properties will be displayed (in a similar format the the Immediate window).

using System;

using System.Diagnostics;

///

/// Any class with a default constructor can be used as an Ad Hoc test fixture.

/// Target an individual method to run as a test and dump returned object (if any).

///

class AdHoc : IDisposable

{

// SetUp using default constructor.

private AdHoc()

{

Trace.WriteLine("SetUp");

}

 

// Dump the fields and properties of any returned complex object.

public AppDomain TestComplex()

{

return AppDomain.CurrentDomain;

}

 

// Enumerate the values of any returned object implementing IEnumerable.

public string[] TestEnumerable()

{

return new string[] {"Test1", "Test2", "Test3"};

}

 

// Test methods can be private and/or static.

private static string TestPrivateStatic()

{

return "No SetUp or TearDown for static methods";

}

 

// TearDown using IDisposable interface.

void IDisposable.Dispose()

{

Trace.WriteLine("TearDown");

}

}

Note: The 'New Project...' wizards aren't showing up in Visual Studio.NET 2003 Beta. Using Ad Hoc tests will be an easy way of giving the addin a spin.

Posted by Jamie Cansdale | with no comments

Installing JUnit & NUnit TestRunners

I've now consolidated the nunit and junit test runners into a single installer. I originaly split them because the junit test runner has a dependence on having the J# runtime installed. I had hoped that splitting them into merge modules would do the trick. Unfortunately it's not as simple as that. From what I can work out there is no way of optinally including a merge module in an installer. Instead you must optionally include individual components (files, registry entries etc.) in the merge module or installer. This is a problem when what you want to optionally install is a merge module. I have resorted to using Orca (the MSI editor) to add dependencies to the J# dependency merge module. Now the installer will only check for the J# runtime if the junit test runner is selected.

The NUnitAddin-0.4.85 change log is here.  The beginnings of a user guide is here (okay is't just a bunch of screen shots, but you get the idea ;).

Posted by Jamie Cansdale | 2 comment(s)
Filed under:

NUnitAddin + Visual Studio.NET 2003

I've fixed NUnitAddin so that it works with Visual Studio.NET 2003 (and the original version).  More later about the issues involved in getting it working.  Let me know if you have any problems.
Posted by Jamie Cansdale | 4 comment(s)
Filed under:

Stepping into IL while debugging

.NET Brain Droppings
 This post came across the ADVANCED-DOTNET list several months ago and I had to post it. Many of us want to be able to step into the IL as we are debugging, but we can't. This suggestion was provided as a work around by Craig Andera and seconded by Mike Woodring.  It's a great way to view the IL as your debugging; lets hope MS will make this easier in the 2nd drop of .NET. You can find the post in the archives here.

(1) decompile your assembly using ildasm to get an IL source file that includes the original high level language in interspersed comments.
(2) recompile the IL into an assembly using ilasm.exe
(3) debug the assembly; now able to see source+IL+asm

Has anyone managed to get this working with signed assemblies? I've got a hunch it might be possible with delay signing and the DEVPATH. Has anyone actually done this? I quite fancy stepping into mscorlib...

Posted by Jamie Cansdale | 1 comment(s)
Filed under:

NUnitAddin J# Dependency (Fixed)

The previous build picked up a dependency on having the J# redistributable installed. In this build I've split support for J# NUnit and junit projects into a separate installer. Install both packages if you want support for junit and all J# 'New Project...' wizards.

Thankyou everyone who let me know about this issue. Could you post a comment here and let me know if it works?

Is anyone using the run all tests in namespace functionality? The reason I ask is because having support for this makes support for multiple test runners tricky. I'm thinking of only supporting run test method, class, project and assembly in future versions.

Posted by Jamie Cansdale | 3 comment(s)
Filed under:
More Posts Next page »