«

N-N-N-N-N-NUnit!

As usual, I’m late to the party but ready to drink. I’ve just started using NUnit for my unit testing needs and it’s been a pleasure to use so far.

I’m generally hesitant to pick up new tools that can be disruptive to my work style, but NUnit fits right in to my normal way of doing things. I write mostly middle tier stuff, so I start new tasks by creating a library project for my real code and a console application to unit test the library. Using NUnit was as simple as adding a reference to the NUnit.Framework assembly to my console project, adding the two NUnit attributes, and changing some of my Console.WriteLine statements to use the NUnit.Framework.Assertion class. Best of all, I can add the necessary stuff without losing the ability to run my unit tests as straight console apps at times when I don’t want to use NUnit.

The NUnit.Framework.TestFixtureAttribute attribute is added to any class which hosts methods which are tests. The NUnit.Framework.TestAttribute attribute is added to the methods themselves. So for example:

 using MyAssembly; using NUnit.Framework;[TestFixture] public class DataTests {    [Test]  public void TestAdding()    {       int result = myClass.GetANumber();      Console.WriteLine("The result was {0}", result);        if (result <> 7)          Console.WriteLine("The result wasn't 7.");  } } 

That gets me half the way there. If I now add a call to the NUnit.Framework.Assertion class, I’m ready to start testing:

 using MyAssembly; using NUnit.Framework;  [TestFixture] public class DataTests {  [Test]  public void TestAdding()    {       int result = myClass.GetANumber();          Console.WriteLine("Called GetANumber sucessfully!");        if (result <> 7)          Console.WriteLine("The result wasn't 7.");                   Assertion.AssertEquals("The result wasn't 7.",          result, 7);             } } 

Once I’ve compiled my solution (including both projects), I switch over to the NUnit GUI (I’m a mort, sue me ;)) and open the console EXE. Boom, I’m cooking with gas.

Almost. I’m an avowed System.Diagnostics.Trace junkie, and there doesn’t seem to be an easy way to get NUnit to display trace output. So I thought to myself, “Pickabar, what would Steve do?” I decided to create a TraceListener which would write the trace output to the console. That took all of 15 seconds (thanks SnippetCompiler!):

 public class ConsoleTraceListener : TextWriterTraceListener {     public ConsoleTraceListener() : base(Console.OpenStandardOutput())  {   } } 

ConsoleTraceListener is a class that derives from System.Diagnostics.TextWriterTraceListener class with a call to that classes constructor using the console’s output stream as an argument. There’ll be a similar class in the framework in the Whidbey release, but for now we’ll have to muddle through ourselves. ConsoleTraceListener let’s us add the TraceListener to the collection used by the NUnit GUI assembly by just touching it’s application configuration file (nunit-gui.exe.config):

 <?xml version="1.0" encoding="Windows-1252"?> <configuration>   <appSettings>     <!--   User application and configured property settings go here.-->     <!--   Example: <add key="settingName" value="settingValue"/> -->     <add key="toolTip.ShowAlways" value="False" />     <add key="shadowfiles.path" value="%temp%\nunit20\ShadowCopyCache" />   </appSettings>  <!---added by me--> <system.diagnostics>     <trace autoflush="false" indentsize="4">         <listeners>            <add name="myListener" type="gTraceListeners.ConsoleTraceListener, gTraceListeners" />         </listeners>     </trace> </system.diagnostics> <!---/added by me-->  </configuration> 

Now I can view the trace output inline with the console output inside of the NUnit GUI. So what was that, a few lines of code and two attributes? I’m winded!