TestFixtureAttribute (NUnit 2.0 / 2.5)
This is the attribute that marks a class that contains tests and, optionally, setup or teardown methods. NUnit 2.5 introduces parameterized and generic test fixtures - see below.
Most restrictions on a class that is used as a test fixture have now been eliminated. As of NUnit 2.5.3, a test fixture class:
- May be public, protected, private or internal.
- May be a static class in .NET 2.0 or later.
- May be generic, so long as any type parameters are provided or can be inferred from the actual arguments.
- May not be abstract - although the attribute may be applied to an abstract class intended to serve as a base class for test fixtures.
- If no arguments are provided with the TestFixtureAttribute, the class must have a default constructor.
- If arguments are provided, they must match one of the constructors.
If any of these restrictions are violated, the class is not runnable as a test and will display as an error.
It is advisable that the constructor not have any side effects, since NUnit may construct the object multiple times in the course of a session.
Beginning with NUnit 2.5, the TestFixture attribute is optional for non-parameterized, non-generic fixtures. So long as the class contains at least one method marked with the Test, TestCase or TestCaseSource attribute, it will be treated as a test fixture.
Example:
namespace NUnit.Tests
{
using System;
using NUnit.Framework;
[TestFixture]
public class SuccessTests
{
// ...
}
}
Imports System
Imports Nunit.Framework
Namespace Nunit.Tests
<TestFixture()> Public Class SuccessTests
' ...
End Class
End Namespace
#using <Nunit.Framework.dll>
using namespace System;
using namespace NUnit::Framework;
namespace NUnitTests
{
[TestFixture]
public __gc class SuccessTests
{
// ...
};
}
#include "cppsample.h"
namespace NUnitTests {
// ...
}
package NUnit.Tests;
import System.*;
import NUnit.Framework.TestFixture;
/** @attribute NUnit.Framework.TestFixture() */
public class SuccessTests
{
// ...
}
Inheritance
The TestFixtureAttribute may be applied to a base class and is inherited by any derived classes. This includes any abstract base class, so the well-known Abstract Fixture pattern may be implemented if desired.
In order to facilitate use of generic and/or parameterized classes, where the derived class may require a different number of arguments (or type arguments) from the base class, superfluous TestFixture attributes are ignored, using the following rules:
- If all TestFixture attributes provide constructor or type arguments, then all of them are used.
- If some of the attributes provide arguments and others do not, then only those with arguments are used and those without arguments are ignored.
- If none of the attributes provide arguments, one of them is selected for use by NUnit. It is not possible to predict which will be used, so this situation should generally be avoided.
[TestFixture]
public class AbstractFixtureBase
{
...
}
[TestFixture(typeof(string))]
public class DerivedFixture<T> : AbstractFixtureBase
{
...
}
Parameterized Test Fixtures (NUnit 2.5)
Beginning with NUnit 2.5, test fixtures may take constructor arguments. Argument values are specified as arguments to the TestFixture attribute. NUnit will construct a separate instance of the fixture for each set of arguments.
Individual fixture instances in a set of parameterized fixtures may be ignored. Set the Ignore named parameter of the attribute to true or set IgnoreReason to a non-empty string.
Individual fixture instances may be given categories as well. Set the Category named parameter of the attribute to the name of the category or to a comma-separated list of categories.
Example
The following test fixture would be instantiated by NUnit three times, passing in each set of arguments to the appropriate constructor. Note that there are three different constructors, matching the data types provided as arguments.
[TestFixture("hello", "hello", "goodbye")]
[TestFixture("zip", "zip")]
[TestFixture(42, 42, 99)]
public class ParameterizedTestFixture
{
private string eq1;
private string eq2;
private string neq;
public ParameterizedTestFixture(string eq1, string eq2, string neq)
{
this.eq1 = eq1;
this.eq2 = eq2;
this.neq = neq;
}
public ParameterizedTestFixture(string eq1, string eq2)
: this(eq1, eq2, null) { }
public ParameterizedTestFixture(int eq1, int eq2, int neq)
{
this.eq1 = eq1.ToString();
this.eq2 = eq2.ToString();
this.neq = neq.ToString();
}
[Test]
public void TestEquality()
{
Assert.AreEqual(eq1, eq2);
if (eq1 != null && eq2 != null)
Assert.AreEqual(eq1.GetHashCode(), eq2.GetHashCode());
}
[Test]
public void TestInequality()
{
Assert.AreNotEqual(eq1, neq);
if (eq1 != null && neq != null)
Assert.AreNotEqual(eq1.GetHashCode(), neq.GetHashCode());
}
}
Generic Test Fixtures (NUnit 2.5)
Beginning with NUnit 2.5, you may also use a generic class as a test fixture. In order for NUnit to instantiate the fixture, you must either specify the types to be used as arguments to TestFixtureAttribute or use the named parameter TypeArgs= to specify them. NUnit will construct a separate instance of the fixture for each TestFixtureAttribute you provide.
Example
The following test fixture would be instantiated by NUnit twice, once using an ArrayList and once using a List<int>.
[TestFixture(typeof(ArrayList))]
[TestFixture(typeof(List<int>))]
public class IList_Tests<TList> where TList : IList, new()
{
private IList list;
[SetUp]
public void CreateList()
{
this.list = new TList();
}
[Test]
public void CanAddToList()
{
list.Add(1); list.Add(2); list.Add(3);
Assert.AreEqual(3, list.Count);
}
}Generic Test Fixtures with Parameters (NUnit 2.5)
If a Generic fixture, uses constructor arguments, there are three approaches to telling NUnit which arguments are type parameters and which are normal constructor parameters.
- Specify both sets of parameters as arguments to the TestFixtureAttribute.
Leading System.Type arguments are used as type parameters, while
any remaining arguments are used to construct the instance. In the
following example, this leads to some obvious duplication...
[TestFixture(typeof(double), typeof(int), 100.0, 42)] [TestFixture(typeof(int) typeof(double), 42, 100.0)] public class SpecifyBothSetsOfArgs<T1, T2> { T1 t1; T2 t2; public SpecifyBothSetsOfArgs(T1 t1, T2 t2) { this.t1 = t1; this.t2 = t2; } [TestCase(5, 7)] public void TestMyArgTypes(T1 t1, T2 t2) { Assert.That(t1, Is.TypeOf<T1>()); Assert.That(t2, Is.TypeOf<T2>()); } } - Specify normal parameters as arguments to TestFixtureAttribute
and use the named parameter TypeArgs= to specify the type
arguments. Again, for this example, the type info is duplicated, but
it is at least more cleanly separated from the normal arguments...
[TestFixture(100.0, 42, TypeArgs=new Type[] {typeof(double), typeof(int) } )] [TestFixture(42, 100.0, TypeArgs=new Type[] {typeof(int), typeof(double) } )] public class SpecifyTypeArgsSeparately<T1, T2> { T1 t1; T2 t2; public SpecifyTypeArgsSeparately(T1 t1, T2 t2) { this.t1 = t1; this.t2 = t2; } [TestCase(5, 7)] public void TestMyArgTypes(T1 t1, T2 t2) { Assert.That(t1, Is.TypeOf<T1>()); Assert.That(t2, Is.TypeOf<T2>()); } } - In some cases, when the constructor makes use of all the type parameters
NUnit may simply be able to deduce them from the arguments provided.
That's the case here and the following is the preferred way to
write this example...
[TestFixture(100.0, 42)] [TestFixture(42, 100.0)] public class DeduceTypeArgsFromArgs<T1, T2> { T1 t1; T2 t2; public DeduceTypeArgsFromArgs(T1 t1, T2 t2) { this.t1 = t1; this.t2 = t2; } [TestCase(5, 7)] public void TestMyArgTypes(T1 t1, T2 t2) { Assert.That(t1, Is.TypeOf<T1>()); Assert.That(t2, Is.TypeOf<T2>()); } }