30

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?

Sly
  • 15,046
  • 12
  • 60
  • 89
SiberianGuy
  • 24,674
  • 56
  • 152
  • 266

3 Answers3

26

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)

ybakos
  • 8,152
  • 7
  • 46
  • 74
  • 3
    I agree with you. It was a mistake. Once it is there it is hard to take back. However I do think there was similar behavior in JUnit at the time. I could be completely wrong. This was all in early 2002 and I could be remembering it incorrectly. Either way you are correct in your assertion that a test class and a fixture are different things. – Mike Two May 20 '12 at 10:48
  • 2
    Thanks Mike Two, I'm always fascinated by the storied histories behind the projects in our craft. I also realize that if I don't like it, I should't whine but submit a patch. I just wonder if I'm overly pedantic since no one else had made this change to NUnit to date. – ybakos May 20 '12 at 19:57
  • 1
    I considered changing it a couple of times. I hit a wall of issues with backwards compatibility. I stopped regular NUnit work years ago so I don't intend to change it in the future. – Mike Two May 20 '12 at 20:37
22

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].

Mike Two
  • 44,935
  • 9
  • 80
  • 96
5

Now that you ask about it, I just looked it up.
A test fixture is the fixed baseline state that must be established before the tests are run, such that the results are predictable and repeatable. In unit testing frameworks, we use the SetUp and TearDown attributes/methods to create/destroy the test fixture (e.g. initialize instance variables with the right objects).

Gishu
  • 134,492
  • 47
  • 225
  • 308