Introduction

This article presents a new way of creating unit tests. Rather than creating a fixture for each class, we split the testing effort by class functionality. Taking advantage of interface composition, we use split the unit tests for each interface and we feed those fixtures using factories. This is why I call this technique: Composite Unit Testing.

There are several advantages of using this approach:

Expressing requirements: interfaces are a natural place for expressing requirements, which later on translate into unit tests,

Test reusability: once you have design a test suite for an interface, you can apply it to any class that implements this interface,

Separation of tests and tested instance generation: the code that generates the tested instances is located in factories that can be reused for each fixtures.

In the rest of the article, I will illustrate this technique on ArrayList and Hashtable.

Test Case

Let us consider illustrate the process with two classes of the System.Collections namespace: ArrayList and Hashtable.

The two classes belong to different families of containers: ArrayList is a sequential container, while Hashtable is an associative container. However, as the interface diagram below shows, they share a lot of functionalities (enumeration, cloneable, serialization, etc...). These functionalities are usually represented by interface composition: ICloneable, ISerializable, etc... The interface define functionalities and requirements on those functionalities.

If you take the usual unit testing methodology, you will need to write two (huge) fixture to test the two classes. Since they share functionality, you will end up duplicating testing code, maintenance problem will increase, etc...

Composite unit testing provides a flexible solution to those problems. In the following, I will illustrate how it is implemented in MbUnit.

Composite Unit Testing Methodology

As mentioned in the introduction, composite unit testing fits naturally in the TDD idea. The principal steps of the process are:

create the interface and express requirements,

create the interface fixture and translate the requirements into unit tests,

implement the interface,

create a class factory that provides instances of the interface,

link fixture to factories and run...

Step 1: Create the interface

This is where you define the functionalities and the requirements. If the documentation is clear enough, it should translate naturally into unit tests. (In this example, the job is already done).

Step 2: Create the interface fixture (for IEnumerable)

MbUnit defines a new custom attribute TypeFixture that is used to create fixture for types (classes, structs or interface). TypeFixture constructor take the type that is tested as argument. Let us start with the fixture of IEnumerable:

using System;
using System.Collections;
using MbUnit.Core.Framework;
using MbUnit.Framework;
[TypeFixture(typeof(IEnumerable))]publicclass EnumerableTest
{}

The test case in EnumerableTest will receive an instance of the tested type (IEnumerable here) as argument. Therefore, the correct signature of those methods is as follows:

The argument is the only difference with the "classic" unit test. You can use test decorators like ExpectedException, Ignore, etc... as usual. IEnumerable defines one method, GetEnumerator. The only requirement is that the IEnumerator instance is not a null reference:

That's pretty short but there is nothing else to test. If you want to test the enumeration, you need to write another fixture for IEnumerator. By defining fixtures for each interface you quickly increase the coverage of the tested code.

Step 4: Create the factories

(We have skipped step 3, the implementation step)

A factory is simply a class that defines public properties or method (with no arguments) that return an object to be tested. You can use factories to provide different flavor of the same class: an empty ArrayList, randomly filled, ordered filled, etc... For example, a possible factory for ArrayList is:

ProviderFactory takes the type of the factory, and the tested type as argument. The framework will take care of exploring by reflection the factories, select the suitable properties and feed the fixtures with created test instances.

Step 6: Running the tests

The full source of the example is available in the demo project. You need to create a new C# assembly project and add the reference to MbUnit.Core.dll and MbUnit.Framework.dll, which you can download from the MbUnit web site: http://mbunit.tigris.org.%20/

Launch MbUnit.GUI and load the assembly (right click -> Assemblies -> Add Assemblies...). Here are some screenshots of the application:

Conclusion

This article has presented composite unit testing, a new strategy for designing and implementing unit testing. Awaiting comments

Reference

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Share

About the Author

Jonathan de Halleux is Civil Engineer in Applied Mathematics. He finished his PhD in 2004 in the rainy country of Belgium. After 2 years in the Common Language Runtime (i.e. .net), he is now working at Microsoft Research on Pex (http://research.microsoft.com/pex).

Yes, I'm using SharpDevelop on a machine that does not support VS.NET (not enough space). The latest version is really better but it is still desesperatly lacking the debugger.

SharpDevelop is already bundled with NUnit, so maybe a "hack" is possible but I have not found any doc on how to write an Add-in for #devel.

ps: I am actively working with Jamie Cansdale to integrate MbUnit with NUnitAddIn which makes VS integration a piece of cake. In fact, in the future, MbUnit should be distributed as a bundle MbUnit/NUnitAddIn.

Jonathan de Halleux wrote:The latest version is really better but it is still desperatly lacking the debugger.

From their wiki:
Add a new Tool (Tools->Options->Tools->External Tools->Add)
Title it Debugger or something like that
In Command search for DbgCLR.exe (usually in C:\Program Files\Microsoft.NET\SDK\v1.1\GuiDebug\DbgCLR.exe)
In Arguments type "${TargetPath}" (NOTE: type the quotes too!)
Hit the OK-Button
Now you can start the debugger with a single click!

Jonathan de Halleux wrote:I am actively working with Jamie Cansdale to integrate