Parent-Child Unit Tests

So, I’m kind of wondering if something like this exists. I currently have a set of tests that share common set up code which I only want to execute once for all of the tests, as well as some set up code that I want executed before each test. In addition, though, there are sets of tests that share test set up that I want to execute only once for that set of tests. Basically here’s what I want to happen

Parent Fixture Set Up
    Child Fixture Set Up
        Parent Set Up
        Child Set Up
            Test
        Child Tear Down
        Parent Tear Down

        Parent Set Up
        Child Set Up
            Test
        Child Tear Down
        Parent Tear Down

        (Etc…)
    Child Fixture Tear Down
    Child Fixture Set Up
        (Etc…)
    Child Fixture Tear Down
Parent Fixture Tear Town

There’s two ways I can see of doing this. One: through inheritance. Basically, the parent / child relationship is expressed through a base / derived relationship. NUnit may support this, but I haven’t tried it. I’m not really sure what happens when you provide two SetUp attributes for one class to NUnit (even if they are a base / derived relationship)

Second, and this is the method I would like to use, you could do it through a containment system. The parent contains the child, like so:

[TestFixture]
public class ParentFixture
{
	[FixtureSetUp]
	public void FixtureSetUp()
	{
	}
	[FixtureTearDown]
	public void FixtureTearDown()
	{
	}

	[TestFixture]
	public class ChildFixture
	{
             // etc.
	}
}

The only problem there is that in order to access, say, private data or methods of the parent class, you need to pass the parent class in as a parameter to the child. I’m pretty sure this is not supported by NUnit.

Does anyone know of an addin that might do this? Has anyone had a similar use case for any unit testing environment? How do you get around it?

2 Responses to “Parent-Child Unit Tests” »»

  1. Comment by David Ludwig | 04/13/08 at 12:11 pm

    I have not yet run into a case whereby I needed to have data be shared among several unit tests. If I was doing work with large databases, I might want to do this, however most of the unit tests I’ve needed to write ran fairly quickly.

    Just how slow would it be to do a set up and tear down for each test case you are working with? Could some of those cases use mocks instead of a real DB, or is that infeasible?

    Regarding hierarchical fixtures, I’ve used such in a C++ library, UnitTest++. With this library, fixtures were still set up as classes, however the set up and tear down code would be placed in the class’ constructor and destructor, as opposed to separate, “SetUp()” and “TearDown()” methods. Child fixtures would either subclass the parent fixture, or include the parent using aggregation. In either case, it was the C++ compiler’s job to make sure that each class’ set up and tear down code was called in the correct order.

  2. Comment by Jeff | 04/16/08 at 11:20 am

    The setup / teardown are actually extremely slow, because they all involve generating code. It’s not slow, but it’s not fast either, so generating before each test isn’t an option if I want the tests to finish in a reasonable amount of time.

    As for using mock objects, unfortunately that’s not an option because what I’m testing is the generated syntax against the actual database. A mock object can’t actually tell me if the database syntax is *actually* correct. These are technically integration or functional tests, but they’re using the same unit test library anyway.

Leave a Reply »»