There are three ways to organize unit tests: Test per Fixture, Class or Feature. But NUnit attribute for TestClass is called TestFixture. Are there any historical reasons for that?
The TestFixture attribute is required however for parameterized or generic test fixture because in that case you also specify additional information through the attribute (parameters/concrete types).
This is the attribute that marks a class that contains tests and, optionally, setup or teardown methods. Most restrictions on a class that is used as a test fixture have now been eliminated.
The [TestFixture] attribute denotes a class that contains unit tests. The [Test] attribute indicates a method is a test method. Save this file and execute dotnet test to build the tests and the class library and then run the tests. The NUnit test runner contains the program entry point to run your tests.
This is the attribute that marks a class that contains the one-time setup or teardown methods for all the test fixtures under a given namespace. The class may contain at most one method marked with the OneTimeSetUpAttribute and one method marked with the OneTimeTearDownAttribute.
I respect Mike Two's response, but I would assert that the NUnit team got this very wrong, and the use of [TestFixture]
is a semantic wart on the face of NUnit. A test class is not a fixture. From what I've dug into with regard to JUnit, I have not found any reference to a test class as a test fixture, nor have I found much discussion about "test fixtures" referring to test classes. Rather, all the JUnit/xUnit discussion about fixtures pertain to setup and teardown, which, of course, are the common methods used to set up actual test fixtures.
Note that in NUnit 2.5, you can remove the [TestFixture] annotation.
Update: (July 2012)
I was just reading the Cucumber Book and on page 99, author Matt Wynne explains the origin of using "fixture." I quote:
There is a long tradition (coming from the hardware world, where test fixtures originated) of calling the link between the test system and the system under test a fixture. This is the "glue code" role that we've referred to in this book as automation code. The FIT testing framework uses this meaning of the term. Some unit testing tools (such as NUnit) have further confused the issue by referring to the test case class itself as a fixture. So much for a ubiquitous language! (Wynne & Hellesoy, 2012)
The main historical reason is that NUnit started life as a straight port from JUnit and junit called it test fixture.
NUnit 1.0 was before my time but I've been told it started out by renaming all of the .java files in JUnit to .cs files and trying to compile. It was fixed up from there and a UI was added. When I joined on for NUnit 2.0 there was still a method in NUnit 1.0 called IsVisualAgeForJava
since JUnit had special behavior for that at the time.
In NUnit 2.0 our aim was to make NUnit more .NETish. So we added the attributes and a bunch of other stuff. All of us came from java backgrounds and had worked with JUnit for years. It seemed quite natural to use [TestFixture]
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With