TestDriven.NET by Jamie Cansdale

Trace Writer & Synchronicity

Trace.Write & Debug.Write

(Note: This is a two part blog post. First part is a product announcement, second part is a question to developers)

I've written a small program called TraceMonitor that is used to capture output from Trace.Write & Debug.Write, etc. I'm re-releasing it to the development community in the hopes that some people can get some use out of it. It's based on DBMon.exe, but allows a finer granularity in filtering and display. It displays an aggregate log, and also splits output from each program into it's own log so you can view an individual session. You can get it at http://www.szurgot.net/projects/default.aspx under TraceMonitor.

[ From Chris Szurgot's Blog ]

Isn’t synchronicity weird? Just this last week I’ve been looking for a way to do this.  What I really want is a light weight back channel for test results and trace output.  At the moment NUnitAddin uses .NET Remoting to send back test results from the test runner.  This works fine until you come to work on a channel sink multi-process application.  If you do you’ll find that outputting trace information affects the code you’re testing or doesn’t show up at all.  Most of the test runners accessible from the 'Test With...' in fact use stderr to communicate back to the addin.  This was originally because I couldn’t count on the .NET Remoting support in Mono and Rotor.  It has also proven to be useful when checking that the test runner process isn’t causing any side effects (in the case of Test With… .NET 1.0 or 1.1).  With this trace monitor code it looks like there is a better way!

AttachDBFileName

I never knew you could do the following with SQL Server connection strings!  This should make unit testing DB code a whole lot easier...

AttachDBFileName=c:\MyFolder\MyDB.mdf

See connectionstrings.com or MSDN for more.  Taken from the comments here.

Java, junit and J#

I've been doing some work on an ongoing Java project recently.  Although JBuilder has some neat unit testing facilities built in, I was missing the ability to run a test without leaving the method.  Since the code I was working on was business logic rather than GUI code I was able to quickly port it to J#.  Luckily the Java collections classes are supported as well as the Java 1.1 API (this makes all the difference).  I'm now happily unit testing my Java project from inside VS.NET 2003.  Of cause it all still compiles with Java 1.3 as this is the target platform!  I have used the odd .jsl file to mirror or stub out Java code that doesn't work or won't compile.  The most annoying thing is that even though Java and .NET resources work in almost exactly the same way, Class.getResourceAsStream(...) isn't supported!  It takes only a few lines of code to find a .NET resource using a java.lang.Class object.  I'm baffled as to why this isn't supported.

All this means that the junit support in NUnitAddin has recieved a lot more dogfooding.  System.out and System.err will now be redirected to Console.Out and Console.Error when runnting tests with the junit test runner.  I'm now more productive in VS.NET than JBuilder (I can compile and test quicker).  If you're using NUnitAddin for Java development I'd be interested to know how you get on.  You can get the latest build here.

Fun with Mono, Rotor and DTE

I've just posted a new build of NUnitAddin.  You should find running individual tests with the debugger much faster.  It now only builds the current project (rather than the whole solution as it did before).

There are a couple of changes that will simplify testing ActiveX controls and .NET Remoting code.  I have ensured that the test thread is always running as an STA (this should fix any problems with ActiveX controls).  You should also find there are no remoting channels registered in the test AppDomain.

As I have mentioned before there is now a 'Test With...' menu.  This lets you run tests in many different contexts.  For example you can choose to test with the Mono, Rotor, .NET 1.1 or .NET 1.0 runtimes.  You can also choose to run tests inside the VS.NET process.  The fun thing about this is that you can have easy access to the VS.NET automation model. When you 'Test With... VS.NET' you can get hold of the DTE object like this...

using EnvDTE;
 
class TestDTE
{
    public static _DTE DTE
    {
        get { return (_DTE)AppDomain.CurrentDomain.GetData("DTE"); }
    }
 
    public void ListProjects()
    {
        foreach(Project project in DTE.Solution)
        {
           Debug.WriteLine(project.Name);
        }
    }
}

Remember to 'Test With... VS.NET'! I always forget and wonder why it isn't working.

If you want to get it working with Mono/Rotor, have a look in the following directory and make sure the contents of the *.bat files are pointing at the correct locations.

%ProgramFiles%\NUnit Addin\runtimes\NUnitAddin.TestRunner.Runtimes\

The Roman Kiss Phenomenon

The Roman Kiss Phenomenon
A few days ago, Roman Kiss presented the world with the Remoting Probe.
This is just the latest in a line of articles he's published on codeproject.com.

From Dot Net Dan

WordML + WebDAV

Don has just got a WordML to XHTML transform working.  This means I could create a WebDAV front end to my blog and edit entries directly in Word!  Just having the Word spell checking facility makes this worth doing for me.  Is there any chance you send me that XSLT?  ;)