The [TestFixture] attribute has been a fixture (pun intended) of unit testing in .Net since NUnit was released. It simply designates that a class contains tests and possibly some code to set up the test environment before tests and tear it down after tests.
Various alternatives have been proposed:
- MbUnit v2 introduced a variety of different kinds of fixtures, such as [TypeFixture], to capture different test lifecycles.
- MSTest calls this thing a [TestClass], reflecting an emphasis on syntax.
- NSpec replaced [TestFixture] with [Context], reflecting a change in testing philosophy and outlook.
- xUnit.Net eliminated [TestFixture] altogether, since it is sufficient to know that a class contains tests to infer that the class is a fixture.
Now with MbUnit v3, we have unified data-driven testing concerns. The perennial [RowTest] attribute has been eliminated because [Test] is itself adequate for describing a data-driven test. (You can simply replace all occurrences of [RowTest] with [Test] and it will work just as it used to in MbUnit v2.)
Likewise we don't need [TypeFixture] because an ordinary [TestFixture] now supports data-driven features that are a superset of what [TypeFixture] and its fellows once provided.
Should MbUnit keep [TestFixture] at all?
I think it should still retain some attribute to denote that a class is a fixture. Despite the incredible power of the humble [TestFixture] today, there can still be special kinds of fixtures. So I prefer keeping things explicit.
However, there's one more detail. In MbUnit v3 (well, really in Gallio) there is no concept of a test fixture. Tests are recursively composable. A fixture just happens to be a test that contains other test. In fact, fixtures can contain nested fixtures which are subject to the same setup/teardown rules as any other tests they may contain.
Test fixtures are not primitive.
Confusion
We could replace [TestFixture] with [Test] and all would be well.
My concern is that it might not mesh very well with the mental model of testers. There are also quite valid historical reasons to avoid changing the syntax too much.
What do you think?
3 comments:
FWIW I think that the number of times that I forget to add the [TestFixture] attribute is a good indicator of it's worth to me. I tend to agree with keeping things explicit where possible but I think [Test] on the methods is explicit enough to clearly indicate intent at the appropriate granularity.
[Test] explains it pretty succinctly, I think holding onto [TestFixture] is just semantics for semantic's sake.
I forget to add the [TestFixture] attribute many times so I believe that live could be easier without it!
Post a Comment