How do I order execution of NUnit test fixtures?-CodePudding

I have a NUnit test project which has two [TextFixture]s.

I want one of them to run before the other as it deals with file creation. They're currently running in the wrong order.

Given that I can't change the [Test]s or group them into a single unit test, is there a way in which I can have control over test fixture running order?

I have tried [Order(int num)] attribute and have also tried to create a new playlist.

Both of them aren't working.

C#, .NET Framework, NUnit Testing Framework, Windows.

CodePudding user response：

The documentation for [OrderAttribute] states that ordering for fixtures applies within the containing namespace.

Make sure that your fixtures are within the same namespace & that you've applied [OrderAttribute] at the test fixture level:

namespace SameNamespace {
    [TestFixture, Order(1)]
    public class MyFirstFixture
    {
        /* ... */ }
    }

    [TestFixture, Order(2)]
    public class MySecondFixture
    {
        /* ... */ }
    }
}

Also, it's important to remember that while MyFirstFixture will run before MySecondFixture, the ordering of the tests inside is local to the test fixture.

A test with [Order(1)] in MySecondFixture will run after all the tests in MyFirstFixture have completed.

Important note: the documentation also does not guarantee ordering.

Tests do not wait for prior tests to finish. If multiple threads are in use, a test may be started while some earlier tests are still being run.

Regardless, tests should be following the F.I.R.S.T principles of testing, introduced by Robert C. Martin in his book "Clean Code".

The I in F.I.R.ST. stands for isolated, meaning that tests should not be dependable on one another & each test should be responsible for the setup it requires to be executed correctly.

Try your best to eventually combine the tests into one if they are testing one thing, or rewrite your logic in a way where the piece of code being tested by test 1, can be tested isolated from the piece of code being tested by test 2.

This will also have the side effect of cleaner code adhering to SRP.

Win-win situation.