Define your Suite
and then add two methods with attributes to the class:
[TestFixtureSetUp]
for code executed before suite,
[TestFixtureTearDown]
for code executed after suite.
Example code:
public class AllTests
{
[TestFixtureSetUp]
public void Setup()
{
Console.WriteLine("### Run Script BEFORE ###");
}
[TestFixtureTearDown]
public void Teardown()
{
Console.WriteLine("### Run Script AFTER ###");
}
[Suite]
public static IEnumerable Suite
{
get
{
var suite = new ArrayList();
suite.Add(new Assembly1.TestClass1());
suite.Add(new Assembly1.TestClass2());
suite.Add(new Assembly2.TestClass1());
return suite;
}
}
}
Then, run NUnit GUI or NUnit Console using /fixture: command line option.
For example:
nunit-console /fixture:NUnit.Tests.AllTests nunit.tests.dll
Output for above code will be as following:
### Run Script BEFORE ###
***** Assembly1.TestClass1.Test1
***** Assembly1.TestClass1.Test2
***** Assembly1.TestClass2.Test1
***** Assembly1.TestClass2.Test2
***** Assembly2.TestClass1.Test1
### Run Script AFTER ###
However, you can't save such Suite as .nunit file.
As noted at NUnit Suite documentation:
NUnit support for user-defined Suites currently has two
limitations:
- It is not possible to include individual test cases directly in a Suite using the
new approach. Anyone wanting to do so will need to use
the old approach and create an object derive from NUnit.Core.TestCase.
This is not recommended, since it requires a reference to the core
assembly.
- Suites are currently not displayed in the Gui or run automatically by either runner when they are encountered. The historical purpose of
the Suite mechanism was to provide a way of aggregating tests at the
top level of each run. Hence, they are only supported when used with
the /fixture option on the console or gui command line.
Approaches to removing these limitations are being investigated as
part of the planning for future NUnit releases.