NUnit not obeying attribute inheritance

Question

I have an issue with NUnit - wondering if anyone has any ideas.

We're using NUnit 2.5.3.9345 and C# 3.5.

Take the following code:

public class UnitTestBase
{
    [TestFixtureSetUp]
    public void SetUpTestFixture()
    {
        //Do something in base
    }
}

[TestFixture]
public class SomeTestClass : UnitTestBase
{
    [TestFixtureSetUp]
    public void FixtureSetUp()
    {
        //Do something in test class
    }

    [Test]
    public void SomeTest()
    {
        //Some assertion
    }
}

According to the documentation, if I run SomeTestClass.SomeTest(), UnitTestBase.SetUpTestFixture() should be called before SomeTestClass.FixtureSetUp().

This isn't the case - the base method will only be called if I don't provide a [TestFixtureSetUp] method in the derived class.

Any ideas please? Has me really puzzled!

Thanks.

Answer 1

I am not having the problem. I tested the outcome with the following:

Derived Test

[TestFixture]
public class DerivedTest : TestBase
{

    [TestFixtureSetUp]
    public void FixtureSetup()
    {

        File.AppendAllText("Out.txt", string.Format("TestFixtureSetUp From DerivedTest{0}", Environment.NewLine));
    }

    [TestFixtureTearDown]
    public void FixtureTearDown()
    {
        File.AppendAllText("Out.txt", string.Format("TestFixtureTearDown Down From DerivedTest{0}", Environment.NewLine));
    }

    [SetUp]
    public void Setup()
    {
        File.AppendAllText("Out.txt", string.Format("Setup From DerivedTest{0}", Environment.NewLine));
    }
    [TearDown]
    public void Down()
    {
        File.AppendAllText("Out.txt", string.Format("TearDown From DerivedTest{0}", Environment.NewLine));
    }

    [Test]
    public void DoATest()
    {
        File.AppendAllText("Out.txt", string.Format("Did a Test{0}", Environment.NewLine));
    }
}

TestBase

public class TestBase
{

    [TestFixtureSetUp]
    public void BaseTestFixtureSetUp()
    {
        File.AppendAllText("Out.txt", string.Format("TestFixtureSetUp From TestBase{0}", Environment.NewLine));
    }

    [TestFixtureTearDown]
    public void BaseTestFixtureTearDown()
    {
        File.AppendAllText("Out.txt", string.Format("TestFixtureTearDown From TestBase{0}", Environment.NewLine));
    }

    [SetUp]
    public void BaseSetup()
    {
        File.AppendAllText("Out.txt", string.Format("Setup From TestBase{0}", Environment.NewLine));
    }

    [TearDown]
    public void TearDown()
    {
        File.AppendAllText("Out.txt", string.Format("TearDown From TestBase{0}", Environment.NewLine));
    }
}

This produces the following output:

TestFixtureSetUp From TestBase
TestFixtureSetUp From DerivedTest
Setup From TestBase
Setup From DerivedTest
Did a Test
TearDown From DerivedTest
TearDown From TestBase
TestFixtureTearDown Down From DerivedTest
TestFixtureTearDown From TestBase

I am was able to test the output with ReSharper 5 beta and the Nunit GUI v 2.5.3.9345 (32-bit)

Edit While at work the test runner in ReSharper 4.5 did not work properly, however running the built test project in x86 and x64 with the corresponding NUnit.exe/NUnit-86.exe produced valid output.

Answer 2

A workaround / different way of doing it:

Instead of relying on behaviour that is not immediately clear, do something like this instead using the template method pattern to make the ordering explicit using normal language features:

public class UnitTestBase
{
    protected abstract void PerFixtureSetUp();

    [TestFixtureSetUp]
    public void SetUpTestFixture()
    {
        PerFixtureSetUp();
    }
}

[TestFixture]
public class SomeTestClass : UnitTestBase
{
    protected override void PerFixtureSetUp()
    {

    }

    [Test]
    public void SomeTest()
    {
        //Some assertion
    }
}

Any time I have had reason to use inherited fixtures or test contexts, this way has worked well enough. :)

My problem with relying on the attributes is that since these types are created and invoked via reflection in the runner with no relation between the methods, (no polymorphism) it's harder to reason about the order in which they're called. Using standard language features helps simplify this a little.