Click here to Skip to main content
13,588,616 members
Click here to Skip to main content
Add your own
alternative version


38 bookmarked
Posted 16 May 2004

Composite Unit Testing with MbUnit

, 16 May 2004
Rate this:
Please Sign up or sign in to vote.
A new way of building test fixtures by taking advantage of interface compositions.


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:

  1. Expressing requirements: interfaces are a natural place for expressing requirements, which later on translate into unit tests,
  2. Test reusability: once you have design a test suite for an interface, you can apply it to any class that implements this interface,
  3. Test Driven Developement: this approach fits nicely and naturally into the TDD paradigm since execution path is interface -> interface fixture -> implementation(s).
  4. 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.

ArrayList and Hashtable

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:

  1. create the interface and express requirements,
  2. create the interface fixture and translate the requirements into unit tests,
  3. implement the interface,
  4. create a class factory that provides instances of the interface,
  5. 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;

public class 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:

public class EnumerableTest
    public void EmptyTest(IEnumerable en)

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:

public class EnumerableTest
    public void GetEnumeratorNotNull(IEnumerable en)

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.

Composition of tests

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:

public class ArrayListFactory
    public ArrayList Empty
             return new ArrayList();
    public ArrayList RandomFilled()
         ArrayList list = new ArrayList();
         Random rnd = ...;
         for(int i=0;i<15;++i)        
         return list;

Note that a factory does not need any particular attributes. Similarly we can define HashtableFactory.

Step 5: Linking the fixtures to the factories

Linking the factories to the fixtures is simply done by using another custom attribute: ProviderFactory.

public class EnumerableTest

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:

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

MbUnit GUI

MbUnit report


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


  1. MbUnit.
  2. My blog :),


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.

A list of licenses authors might use can be found here


About the Author

Jonathan de Halleux
United States United States
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 (

You may also be interested in...


Comments and Discussions

GeneralInteresting article. Pin
David Piepgrass27-May-04 12:29
memberDavid Piepgrass27-May-04 12:29 
By the way, what tool do you use to create all those nifty diagrams in your article?
GeneralRe: Interesting article. Pin
Jonathan de Halleux27-May-04 15:29
memberJonathan de Halleux27-May-04 15:29 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web04 | 2.8.180615.1 | Last Updated 17 May 2004
Article Copyright 2004 by Jonathan de Halleux
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid