What is the order of execution in NUnit?

Question

I have been doing some research on test driven development and find it pretty cool.

One of the things I came across was that when you write your tests, there is an order of execution of your setup and test methods ([Setup] and [Test]).

Are there others that you can use while testing and if so what is the execution order of those, such as a dispose or something? I saw test fixture setup, but not too familiar with that one.

Example:

When I run the test, it does the [Setup] first and then runs the [Test] when it goes to the next test it runs the [Setup] again and then goes to the [Test].

I am using NUnit if that helps.

Here is a truncated example of what I have setup:

using NUnit.Framework;

    namespace TestingProject
    {
        [TestFixture]
        public class CustomerService_Tests
        {
            public string MyAccount = string.Empty;

            [SetUp]
            public void Setup()
            {
                MyAccount = "This Account";
            }

            [Test]
            public void Validate_That_Account_Is_Not_Empty()
            {
                Assert.That(!string.IsNullOrEmpty(MyAccount));
            }

            [Test]
            public void Validate_That_Account_Is_Empty()
            {
                Assert.That(string.IsNullOrEmpty(MyAccount));
            }
        }
    }

So, when I run the tests, it does the setup, and then the first test, then setup and then the 2nd test.

My question is what other types can I use while testing such as [Setup] and [Test] and what is the order of execution for these.

Answer 1

Using NUnit (not sure about others) you have the following order of executions:

TestFixtureSetup

Setup

Test

TearDown

Setup

Test

TearDown

TestFixtureTearDown

Every time you run your tests it will always execute in that order.

If you take a look at the following code, you can see an exact replica of what I am talking about. You can even copy and paste this code and it should work (using NUnit, not sure if it will work with others).

If you run this in debug mode, and put a break point on each of the methods, you can see the order of execution while you debug.

using NUnit.Framework;

namespace Tester
{
    [TestFixture]
    public class Tester
    {
        public string RandomVariable = string.Empty;

        [TestFixtureSetUp]
        public void TestFixtureSetup()
        {
            //This gets executed first before anything else
            RandomVariable = "This was set in TestFixtureSetup";
        }

        [SetUp]
        public void Setup()
        {
            //This gets called before every test
            RandomVariable = "This was set in Setup";
        }

        [Test]
        public void MyTest1()
        {
            //This is your test...
            RandomVariable = "This was set in Test 1";
        }

        [Test]
        public void MyTest2()
        {
            //This is your test...
            RandomVariable = "This was set in Test 2";
        }

        [TearDown]
        public void TestTearDown()
        {
            //This gets executed after your test gets executed. 
            //Used to dispose of objects and such if needed
            RandomVariable = "This was set in TearDown";
        }

        [TestFixtureTearDown]
        public void TestFixtureTearDown()
        {
            //Executes Last after all tests have run.
            RandomVariable = "This was set in TestFixtureTearDown";

        }

    }
}

Answer 2

Check out the NUnit documentation:

http://www.nunit.org/index.php?p=attributes&r=2.2.10

The menu down the right hand side under "Attributes" describes [Setup], [Test] and other attributes you can use when developing your tests.

Answer 3

For each class that you have tests in, a test fixture, you can specify 4 special methods. The names of the methods are not really important, but you need to tag the methods with one of the following four attributes in order to identify them.

Convention dictates that you call the methods the same as the attributes though, but as I said, the attributes is the important bit.

Note that the attributes I describe here are the ones found in NUnit, but similar attributes (if not the same) are in use in most unit test frameworks.

The attributes are:

• TestFixtureSetUp
• TestFixtureTearDown
• SetUp
• TearDown

The first two has to do with the class as a whole. The method tagged with the TestFixtureSetUp attribute is run once, before the first test in the class.

After all the tests in the class has been executed, the method tagged with the TestFixtureTearDown attribute is executed, once.

You can use these two to prepare common data structures that are the same for all the tests, and aren't modified by any tests (this is important).

The last two, SetUp and TearDown, are used to tag two methods that will be run before, and after each individual test.

The method tagged with SetUp is called before each test, and the method tagged with TearDown is called after each test. You can use these to prepare common data structures, that though they are the same for each test, they will be changed by some or all of the tests, so it's best to prepare a new fresh copy for each test.

Laying out the execution of these methods as pseudo-code gives us this order:

execute TestFixtureSetUp, if present
for each test do
    execute SetUp, if present
    execute actual test
    execute TearDown, if present
execute TestFixtureTearDown, if present

The usage of these attributes are entirely optional. You do not need to have a SetUp in order to have a TearDown or vice versa. They're just points you might want to execute code at.

Answer 4

Be aware that the best practice is to keep the unit test cases independent of each other. So they can be understood, modified and run independently.

Some consider setup and teardown a bad practice as well. See these links for the reasoning:

• http://jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html
• http://www.agileprogrammer.com/dotnetguy/articles/SetupTeardown.aspx

Answer 5

In NUnit 2.5.1 the order of execution has changed once more. I agree that unittest must never interfere with each other.