Introduction

In NUnit, you should assume tests are independent and should not depend on execution order. By default, NUnit does not guarantee a meaningful business-logic sequence for your tests, and that is intentional because order-dependent tests are fragile.

When order does matter, NUnit gives you a limited way to express it with attributes such as Order, but that should be the exception rather than the design foundation of the suite.

Default Behavior: Do Not Rely on Implicit Order

If you do not specify ordering, NUnit is free to run tests in an implementation-dependent order. That can vary with discovery, filtering, or parallel execution settings.

So this is the wrong assumption:

• test names sort alphabetically
• files run top to bottom
• methods run in the order written in source

Even if that appears true on one machine, it is not a stable contract.

Use Order Only When There Is a Real Reason

NUnit provides an Order attribute for tests in the same fixture or suite.

1using NUnit.Framework;
2
3[TestFixture]
4public class OrderedTests
5{
6    [Test, Order(1)]
7    public void CreateRecord()
8    {
9        Assert.Pass();
10    }
11
12    [Test, Order(2)]
13    public void UpdateRecord()
14    {
15        Assert.Pass();
16    }
17}

Lower order values run first. This can help in integration-style scenarios, but it does not turn order-dependent tests into a good unit-testing design.

Prefer Setup Over Ordered Dependencies

If tests need common preparation, use setup hooks instead of relying on a previous test to prepare state.

1using NUnit.Framework;
2
3[TestFixture]
4public class UserServiceTests
5{
6    private UserService _service;
7
8    [SetUp]
9    public void SetUp()
10    {
11        _service = new UserService();
12    }
13
14    [Test]
15    public void CanCreateUser()
16    {
17        Assert.That(_service.Create("alice"), Is.Not.Null);
18    }
19
20    [Test]
21    public void RejectsEmptyName()
22    {
23        Assert.That(() => _service.Create(""), Throws.ArgumentException);
24    }
25}

This keeps each test self-contained and resilient.

Be Careful with Parallel Execution

Even if you specify order, parallelization can still affect how tests interact when they share mutable resources. If tests touch the same database, filesystem path, or static state, ordering alone is not enough.

In those cases, either isolate the state or explicitly disable parallel execution for the affected fixture.

1using NUnit.Framework;
2
3[TestFixture]
4[NonParallelizable]
5public class SerialIntegrationTests
6{
7    [Test, Order(1)]
8    public void StepOne() { }
9
10    [Test, Order(2)]
11    public void StepTwo() { }
12}

This is more honest than pretending shared-state tests are still unit tests.

What Order Usually Signals About the Test Suite

Needing a fixed order often means one of these is true:

• tests share state
• setup is incomplete
• integration behavior is being tested in unit-test style
• the fixture is too large and should be split

That does not mean ordered tests are forbidden. It means they should trigger a design review.

Common Pitfalls

• Assuming source-code order or alphabetical naming gives a guaranteed NUnit execution order.
• Using one test to prepare data that another test silently depends on.
• Applying Order everywhere instead of fixing shared-state design problems.
• Forgetting that parallel execution can still break ordered tests that share resources.
• Calling an integration workflow a “unit test” and then fighting the framework to preserve sequence.

Summary

• By default, NUnit test order should be treated as unspecified for practical purposes.
• Use Order only when sequence is truly required.
• Prefer SetUp, fresh fixtures, and isolated state over inter-test dependencies.
• Combine ordering with NonParallelizable when shared external resources are unavoidable.
• If order matters a lot, that often signals a test design problem worth fixing.