NUnit question:

[Claus Konrad]

How does one control the order in which a sequence of tests are performed
using NUnit?

e.g.

[Test]
public void BTest()
{
}

[Test]
public void ATest()
{
}

When compiling it seems that the "ATest" is performed before the "BTest",
eventhough the "BTest" is declared first in the TestFixture.

I'm in a situation where the different test can be dependent on each other -
that's why.

/Claus

 

[Julie]

How does one control the order in which a sequence of tests are performed
using NUnit?

e.g.

[Test]
public void BTest()
{
}

[Test]
public void ATest()
{
}

When compiling it seems that the "ATest" is performed before the "BTest",
eventhough the "BTest" is declared first in the TestFixture.

I'm in a situation where the different test can be dependent on each other -
that's why.

/Claus

I'm pretty sure that they are executed in alphabetical order (at least that is
what I've noticed in my unit test).

Regardless, I don't think that it is recommended that you base the effects of
one test on another. I'd recommend moving the the common code to [SetUp] or
explicitly calling the necessary predecessor functions. If you can't do that,
then I guess you need to name your tests in alphabetical execution order.

 

[Peter Rilling]

Tests are suppose to be autonomous. I would suggest refactoring your tests
so that they are not dependent on one another.

But, if you actually need then you could consider explicitly calling the
first test when the second test runs to make sure your state is as you need
it. This would not prevent the test from running a second time, that you
would then have to watch for.

 

[Adam]

But, if you actually need then you could consider explicitly calling the
first test when the second test runs to make sure your state is as you need
it. This would not prevent the test from running a second time, that you
would then have to watch for.

We tried this in a large ish project, and it got quite confusing when
tests called by other tests started to fail. We moved to a combination
of [Setup] and refactored common functions.

When common functionality spanned test classes we moved common
functions to simple base classes (containning no tests).

It still wasn't perfect but it was simple to follow, which has to be
worth a few points.