Click here to Skip to main content
Click here to Skip to main content

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.

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:

  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:

EnumerableTest

using System;
using System.Collections;
using MbUnit.Core.Framework;
using MbUnit.Framework;

[TypeFixture(typeof(IEnumerable))]
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:

[TypeFixture(typeof(IEnumerable))]
public class EnumerableTest
{
    [Test]
    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:

[TypeFixture(typeof(IEnumerable))]
public class EnumerableTest
{
    [Test]
    public void GetEnumeratorNotNull(IEnumerable en)
    {
        Assert.IsNotNull(en.GetEnumerator());
    }
}

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
    {
         get
         {
             return new ArrayList();
         }
    } 
    public ArrayList RandomFilled()
    {
         ArrayList list = new ArrayList();
         Random rnd = ...;
         for(int i=0;i<15;++i)        
             list.Add(rnd.Next());
         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.

[TypeFixture(typeof(IEnumerable))]
[ProviderFactory(typeof(ArrayListFactory),typeof(IEnumerable))]
[ProviderFactory(typeof(HashtableFactory),typeof(IEnumerable))]
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.

Factories

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:

MbUnit GUI

MbUnit report

Conclusion

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

Reference

  1. MbUnit.
  2. My blog Smile | :) , http://blog.dotnetwiki.org/.

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.

A list of licenses authors might use can be found here

About the Author

Jonathan de Halleux
Engineer
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 (http://research.microsoft.com/pex).

Comments and Discussions

 
QuestionAnybody ever reads these topics? PinmemberForis Gabor14-Dec-04 3:19 
AnswerRe: Anybody ever reads these topics? PinmemberMarc Stober21-Dec-06 4:29 
Generaltypefixture parameter problem Pinmemberforis.gabor@stud.u-szeged.hu16-Nov-04 2:40 
GeneralI had the same problem with MbUnit 2.22 Pinmembertim73di4-Apr-05 7:18 
AnswerRe: I had the same problem with MbUnit 2.22 PinmemberLuckyJames15-Aug-06 4:04 
QuestionHow does this test all members? PinmemberKent Boogaart30-May-04 14:27 
AnswerRe: How does this test all members? PinmemberJonathan de Halleux1-Jun-04 23:42 
GeneralRe: How does this test all members? PinmemberKent Boogaart2-Jun-04 14:09 
GeneralRe: How does this test all members? PinmemberJonathan de Halleux2-Jun-04 21:09 
GeneralInteresting article. PinmemberDavid Piepgrass27-May-04 12:29 
GeneralRe: Interesting article. PinmemberJonathan de Halleux27-May-04 15:29 
Generalintegration sharpdevelop PinmemberD4Skunk17-May-04 21:55 
GeneralRe: integration sharpdevelop PinmemberJonathan de Halleux17-May-04 22:33 
GeneralRe: integration sharpdevelop PinmemberD4Skunk18-May-04 0:07 
GeneralRe: integration sharpdevelop PinmemberJonathan de Halleux18-May-04 0:21 

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

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

| Advertise | Privacy | Mobile
Web03 | 2.8.140721.1 | Last Updated 17 May 2004
Article Copyright 2004 by Jonathan de Halleux
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid