When do I use the TestFixtureSetUp attribute instead of a default constructor?

Question

The NUnit documentation doesn't tell me when to use a method with a testfixturesetup en when to do the setup in the constructor

public class MyTest
{
    private MyClass myClass;

    public MyTest()
    {
        myClass = new MyClass();
    }

    [TestFixtureSetUp]
    public void Init()
    {
        myClass = new MyClass();
    }
}

Are there any good/bad practices about the TestFixtureSetup versus default constructor or isn't there any difference?

Answer 1

Why would you need to use a constructor in your test classes?

I use [SetUp] and [TearDown] marked methods for code to be executed before and after each test, and similarly [TestFixtureSetUp] and [TestFixtureTearDown] marked methods for code to be executed only once before and after all test in the fixture have been run.

I guess you could probably substitute the [TestFixtureSetUp] for a constructor (although I haven't tried), but this only seems to break from the clear convention that the marked methods provide.

Answer 2

I think this has been one of the issues that hasn't been addressed by the nUnit team. However, there is the excellent xUnit project that saw this exact issue and decided that constructors were a good thing to use on test fixture initialization.

For nunit, my best practice in this case has been to use the TestFixtureSetUp, TestFixtureTearDown, SetUp, and TearDown methods as described in the documentation.

I think it also helps me when I don't think of an nUnit test fixture as a normal class, even though you are defining it with that construct. I think of them as fixtures, and that gets me over the mental hurdle and allows me to overlook this issue.

Answer 3

I have often wondered what the need for [TestFixtureSetUp] was, given that there is a simple, well understood first class language construct that does exactly the same thing.

My preference is to use constructors, to take advantage of the readonly keyword ensuring member variables cannot be reinitialised.

Answer 4

I think I have a negative good answer - the reason to use a constructor instead of the attribute is when you have an inheritence between test classes.

Only one method annotated with [TestFixtureSetup] will be called (on the concrete class only), but the other fixture initializers will not. In this case I'd rather put the initialization in the constructor, which has a well-defined semantics for inheritance :)

Answer 5

One thing you can't do with [TestFixtureSetup] that you can do in the constructor is receive parameters from the [TestFixture] .

If you want to parameterise your test fixture, then you will have to use the constructor for at least some of the set-up. So far, I've only used this for integration tests, e.g. for testing a data access layer with multiple data providers:

[TestFixture("System.Data.SqlClient",
  "Server=(local)\\SQLEXPRESS;Initial Catalog=MyTestDatabase;Integrated Security=True;Pooling=False"))]
[TestFixture("System.Data.SQLite", "Data Source=MyTestDatabase.s3db")])]
internal class MyDataAccessLayerIntegrationTests
{
    MyDataAccessLayerIntegrationTests(
        string dataProvider,
        string connectionString)
    {
        ...
    }
}