James Crisp » Testing

Green & Red Local Builds (adding colour to the local build process)

James — Thu, 20 Nov 2008 12:13:45 +0000

Well, who doesn't write tests and do continuous integration (CI) these days? Whether you use one of the many Cruise Control variants, or Team City or some other tool, you most likely get a handy colour coding of builds as either green or red (ie, good, or bad). But, you can take this a step further!

Often on .NET projects, we have a little batch file that we run before checking in (often with a pause at the end so it can be run from a shortcut), to confirm that no tests are broken locally. Well, it's not much fun peering at the ugly Nant output (or whatever build system you use). Instead, it is quite easy to add a couple of lines to your batch file and change the colour of the console to bright Red or bright Green depending on the success of the local build. It is great for telling what the result was at a glance. I can't claim credit the idea - it was something we used at EDI for our custom build system, but here's some batch file code I whipped up which I can claim is all mine, every last GOTO of it! Enjoy

The following code uses NAnt, but you can replace it with MsBuild or any other build tool that returns a status code.

@echo off

color 07

tools\nant\NAnt.exe -buildfile:mybuild.build %*

IF ERRORLEVEL 1 goto RedBuild
IF ERRORLEVEL 0 goto GreenBuild

:RedBuild
color 4F
goto TheEnd

:GreenBuild
color 2F

:TheEnd
pause

NUnit Test Runners Were Not All Made Equal

James — Tue, 08 Apr 2008 07:26:11 +0000

NUnit tests can be run using a variety of different runners. Some common ones are:

The NUnit GUI and Test Driven create a new instance of the test class for each test run. This leads to more isolation but potentially slower performance.

Resharper and NUnit MSBuild Task re-use the same instance of the test class when running each test in the class. This can lead to unintended interaction between tests. Using these runners, it is vital to to assign initial values to instance variables in SetUp, rather than when they are defined or in the constructor.

If you use a mix of different test runners, you can end up with tests that pass on some machines and fail on others (eg, Test Driven locally works fine, but you use NUnit MSBuild Task on your build box and get intermittent failures).

NUnit SetUp Attribute and Subclassed Test Cases

James — Tue, 08 Apr 2008 07:05:44 +0000

If you have a ChildTestCase class that inherits from a ParentTestCase class, and both of these have a SetUp method, marked with the [SetUp] attribute, would you expect both to be called? If so, you would be sadly disappointed. Only the SetUp method of the ChildTestCase will be called, and the SetUp in the ParentTestCase will be ignored.

According to the NUnit documentation on the Set Up attribute, this is intended behaviour:

If you wish to add more SetUp functionality in a derived class you need to mark the method with the appropriate attribute and then call the base class method.

An alternative approach to get all your SetUps called is to have a base TestCase class define a protected virtual SetUp() (with the SetUp attribute), which all child classes override (and call base on their first line).