What is a Coding Dojo?

A coding dojo is a meeting, which brings together a number of programmers to work on a programming challenge. It’s mainly about solving the task in a relaxed atmosphere together and to learn new things. A dojo is not a competition, but the focus is on the learning. More information is available at http://codingdojo.org.

What is a Coding Dojo?

A coding dojo is a meeting, which brings together a number of programmers to work on a programming challenge. It’s mainly about solving the task in a relaxed atmosphere together and to learn new things. A dojo is not a competition, but the focus is on the learning. More information is available on http://codingdojo.org.

Test-Driven Development

• Writing Testable Code
  • Isa Goksu writes about writing testable code.
• Moving to Test-Driven Development and Exploring Language Paradigms
  • Eric Hagan interviews Michael Feathers.
• The Problem with xUnit
  • Edward Z. Yang writes about why he believes that xUnit test frameworks lead to more boilerplate code and how to use Haskell to create DSL-like tests with QuickCheck.
• Some Rough Draft TDD Demonstration Videos
  • Brett Schuchert is doing a series of video on TDD. He already published rough drafts of his videos.

Unit Test Frameworks

NUnit

• NUnit 2.5.5 released
  • Charlie Poole released version 2.5.5 of NUnit last Friday. It can be downloaded from here.
• NUnit Template for ASP.NET MVC 2
  • Markus Ewald ported the MSTest unit test templates for ASP.NET MVC 2 to NUnit. It isn’t ready though: it doesn’t add a reference to the ASP.NET project. Details can be found on the NUnit-Discuss mailing list.

MbUnit

• XML Assertions in MbUnit v3
  • Yann Trévin writes about new assertions in the upcoming MbUnit 3.2 which will help with testing XML output.

“A test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can’t run at the same time as any of your other unit tests
• You have to do special things to your environment (such as editing config files) to run it.

Tests that do these things aren’t bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes.”

Developers often even do not write unit tests! They are writing integration tests instead. Sometimes it takes more than knowing the test attributes of the used unit test framework to write real unit tests!

• Windows Installer SDK.aspx) in the MSDN library
• Windows Installer 4.5 SDK: contains tools like Orca or the Windows Installer documentation as CHM file.
• Windows Installer XML (WiX): a toolset that builds Windows Installer packages from XML source code.
• Understanding Microsoft Installer Logs
• Automated Install Testing - MSI Validation
• Conditional Statement Syntax.aspx)

For getting started with WiX:

• Authoring your first .wxs file
• Creating a simple setup (using Votive)
• WiX Tutorial (by Gábor DEÁK JAHN)
• From MSI to WiX (by Alex Shevchuk)
• MSI Validation in WiX (by Derek Cicerone)
• Adding and Customizing Dialogs in WiX 3

Adhoc projects

The Console runner accepts more than one test assemblies as command line arguments. If you use the GUI runner you can add test assemblies by using “Project => Add Assembly…”. But the test assembly must be in the same directory as the assembly which has already been loaded, otherwise NUnit can’t find the file and aborts with a FileNotFoundException.

Creating NUnit projects

You can create a new NUnit test project by clicking on “File => New Project…”. You can add assemblies to the project by clicking on “Project => Add Assembly…”. Using NUnit test projects the test assemblies can be in different directories.

One configuration file for all test assemblies

NUnit can load configuration files for test assemblies even for class libraries. With NUnit test projects you can use just one configuration file. You can change the name of this file in the NUnit project editor, but you can’t specify a file path, just the file name. The configuration file must be located in the same directory as the project file.

In ASP.NET MVC Preview 4 ComponentController has been removed and the method RenderComponent which called the ComponentController action from the view has been replaced by the method RenderAction which can call an action of a normal Controller. Since this concept conflicts with ”Separation of concerns”, Microsoft doesn’t intend to include this feature in the RTM version of ASP.NET MVC.

ASP.NET MVC Futures

Therefore the ASP.NET MVC team moved the RenderAction method to the ASP.NET MVC Futures which consist of the assembly Microsoft.Web.Mvc.dll. This assembly contains features and prototypes which haven’t been included in the RTM version yet. The release for ASP.NET MVC Beta 1 can be downloaded from Codeplex.

In order to use ASP.NET MVC Futures in your MVC project reference the assembly “Microsoft.Web.Mvc.dll” and insert the following line into the web.config to include the namespace “Microsoft.Web.Mvc” in all your views automatically:

SubControllers from MvcContrib

SubControllers can be used for similar purposes like RenderAction or Components. Matt Hinze presented this feature from the MvcContrib project in a blog post. SubController actions can be included in the view data as delegates. The views can then invoke these delegates and start the rendering of the SubController action view.

The host controller can pass objects to the SubController. Matt Hinze explains this feature in another blog post.

• The description of a Row attribute will be copied to the created test case.

You can download it from the RowTest Extension page.

• null cannot be used as argument on .NET Framework 1.1. A new enum value SpecialValue.Null can be used instead. If the RowTest addin finds this value as argument the value will be translated to null.
• Fixed Bug: Common NUnit attributes like Category, Description etc. don’t work for RowTest methods.

You can download it from the RowTest Extension page.

• Fixed Bug: SetUp and TearDown are not called on the RowTest test suite
• Created new Test project for functional tests and reorganized samples.

You can download it from the RowTest Extension page.

• Added build for .NET Framework 1.1.
• Assemblies are now strongly named.
• Added ExceptionMessage property to RowAttribute. It can be used to specify the message of an expected exception.
• Added TestName property to RowAttribute. It is used to provide a custom name of the test. If TestName is null or empty the method name will be used.
• Fixed Bug: TestFixtureSetUp and TestFixtureTearDown are not called on the RowTest test suite (thanks to Wayne Brantley for reporting the bug and special thanks to Jamie Cansdale for providing a fix
• Fixed Bug: When a TestFixture contains both RowTests and normal unit tests the row tests are not alphabetically ordered.

You can download it from here.

• Added ExpectedException property to the [Row] attribute. It can be used to specify which type of exception to expect when the given data is passed to the test.
• The [Row] attribute accepts now null values.
• Removed dependency from assembly NUnitExtension.RowTest.AddIn to NUnitExtension.RowTest.

You can download it from here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[TestFixture]
public class RowTestSample
{
     [RowTest]
     [Row( 1000, 10, 100.0000)]
     [Row(-1000, 10, -100.0000)]
     [Row( 1000, 7, 142.85715)]
     [Row( 1000, 0.00001, 100000000)]
     [Row(4195835, 3145729, 1.3338196)]
     public void DivisionTest(double num, double den, double res)
     {
        Assert.AreEqual(res, num / den, 0.00001);
     }
}

The current release does not support all features of MbUnit RowTests, e.g. Exceptions cannot be tested.

What Is a Test Decorator?

The Decorator Pattern describes a design for attaching additional responsibilities to an object dynamically. It is also known as Wrapper. Test Decorators wrap a single test case or a test fixture and therefore allow you to run some code before and after it.

Typical uses for test decorators are measuring performance or setting up and cleaning up a database.

Copy a File Before Running a Test

(You can find the source for the examples here.)

Assume that a test needs a certain file each time you run a test. If those tests are in the same test fixture and there are no other tests in this fixture, you will use a setup method. Otherwise test decorators may help you. Furthermore test decorators provide a way to share test extensions.

So, let’s start by writing an NUnit addin:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[NUnitAddin(Name="Copy File Decorator Addin",
            Description="Copies a file before running the test.")]
public class CopyFileAddin : IAddin, ITestDecorator
{
  public bool Install(IExtensionHost host)
  {
    IExtensionPoint decorators = host.GetExtensionPoint("TestDecorators");
    if (decorators == null)
      return false;

    decorators.Install(this);
    return true;
  }
}

As CopyFileAddin implements both the IAddin and the ITestDecorator interfaces, it installs itself at the extension point “TestDecorators”. I described the IAddin interface in my last post and ITestDecorator declares the method Decorate and CopyFileAddin implements it as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public Test Decorate(Test test, MemberInfo member)
{
  // Decorate only single test cases
  if (test is TestCase)
  {
    Attribute attribute = Reflect.GetAttribute(
        member, "CopyFileTest.Framework.CopyFileAttribute", false);

    if (attribute != null)
    {
      string sourcePath = (string)Reflect.GetPropertyValue(attribute,
          "SourcePath", BindingFlags.Public | BindingFlags.Instance);
      string destinationPath = (string)Reflect.GetPropertyValue(attribute,
          "DestinationPath", BindingFlags.Public | BindingFlags.Instance);

      test = new CopyFileTestCase((TestCase) test,
          sourcePath, destinationPath);
    }
  }

  return test;
}

In NUnit 2.4 you mark tests to be wrapped by using specific .NET attributes. The test decorator extension identifies those tests and wrap them with a special decorator test case class, e.g. the following test case will be wrapped with a CopyFileTestCase if the CopyFileAddin is properly installed in your NUnit – in my last post I described how to do this.

The attribute CopyFile marks the test case to be wrapped and stores the source and destination path of the file to be copied. The test may be run in another thread, so the paths must be absolute.

The decorator class looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public class CopyFileTestCase : TestCase
{
  private TestCase _testCase;
  private string _sourceFilePath;
  private string _destinationPath;

  public CopyFileTestCase(
      TestCase testCase,
      string sourceFilePath,
      string destinationPath)
      : base((TestName)testCase.TestName.Clone())
  {
    _testCase = testCase;
    _sourceFilePath = sourceFilePath;
    _destinationPath = destinationPath;
  }

  public override void Run(TestCaseResult result)
  {
    if (File.Exists(_sourceFilePath))
      File.Copy (_sourceFilePath, _destinationPath);

    _testCase.Run(result);

    if (File.Exists(_destinationPath))
      File.Delete(_destinationPath);
  }
}

Test Cases And Test Suites

Maybe you are wondering, what the classes Test and TestCase are about. NUnit organizes tests in test cases and test suites and both are tests. They form another design pattern known as Composite.

If your decorator supports single test cases only it will wrap a TestCase, like CopyFileTestCase. You may decorate test suites or both test cases and test suites by wrapping a TestSuite or Test object respectively.

RepeatedTestDecorator and MaxTimeDecorator

NUnit 2.4 already provides a test decorator: the RepeatedTestDecorator. You can find it in the assembly “nunit.framework.extensions.dll”.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

using System;
using NUnit.Framework;
using NUnit.Framework.Extensions;

namespace RepeatedTest
{
  [TestFixture]
  public class RepeatedTestFixture
  {
    private int _count;
        
    [TestFixtureSetUp]
    public void TestFixtureSetUp()
    {
      _count = 0;
    }
        
    [Test]
    [Repeat(5)]
    public void RepeatedTestCase()
    {
      _count++;
      Console.WriteLine(_count);
      if (_count == 5)
        Assert.Fail("The test has been repeated 5 times.");
    }
  }
}

You will have to reference the assembly “nunit.framework.extensions.dll”. The test will fail with the provided message. The NUnit package installs some sample projects and amongst them a solution with examples for the new Core Extensibility features. There you can find the sample decorator MaxTimeDecorator, which fails a test when its duration exceeds a provided limit.

Downsides

Currently there is no way to specify an Addin as requirement. Imagine, you’ve written a unit test using the MaxTimeDecorator. Your test will fail if it runs longer than the provided limit. You commit your changes to your source repository. Your colleague gets the new unit test from the repository and works on the program. Her changes affect the performance of the code and the test lasts longer than required. If she didn’t install the MaxTimeDecorator Addin, she would not notice the defect.

There is currently no mechanism to control the order in which the decorators are applied. NUnit applies decorators in the order in which they are returned through reflection. Therefore pay attention to this issue if you use more than one decorator.

1
2
3
4
5
6
7
8
9
10

[Test]
[Repeat(5)]
[MaxTime(1100)]
public void RepeatedTestCase()
{
  _count++;
  System.Threading.Thread.Sleep(1000);
  if (_count == 5)
    Assert.Fail("The test has been repeated 5 times.");
}

In this example it is not predictable if the test will fail because of the counter or the exceeded time limit. If the RepeatDecorator wraps the MaxTimeDecorator, it will fail because of the counter, otherwise because of the time limit.

More Information

If you need more information about NUnit addins, have a look at the NUnit documentation.