Overstating the obvious with attributes
Why does Team System’s developer testing framework, which I’ve dubbed MSTest, require that any class that implements tests be decorated with a [TestClass] attribute? Why does NUnit require the same semantics (using the [TestFixture] attribute)? If there is a [TestMethod] or [Test] attribute for MSTest and NUnit accordingly, why does one need a class level attribute to signify a testing class? Can’t these frameworks infer this information when they discover a class containing a method level test attribute?
Before you get upset and jump up shouting at your monitor, let me remind you that both JUnit 4 and TestNG do not require this class level declaration (both are Java based testing frameworks, which take advantage of attributes or as they’re known in Java, annotations). Both frameworks infer a test by examining a class’s methods, which if one is decorated with a @Test annotation, the class is assumed to be a test case and its test methods are executed accordingly.
The NUnit documentation states that the attribute [TestFixture] is used to determine if a class is a test case, which, to me, implies that the framework, in some way, scans a collection of classes obviously seeking out tests. So unless there is some magic going on which enables the frameworks to skip scanning a non-decorated class, all classes in a collection get touched (by NUnit) at least once. In that case, why not skip the class level query and query the methods directly? In the case of scanning class level attributes, the methods will have to be scanned anyway once a [TestFixture] is discovered.
Albert Einstein is often quoted as saying “A theory should be as simple as possible, but no simpler.” The use of attributes (or annotations to overstate the obvious) has dramatically simplified authoring developer tests; however, in the case of NUnit and MSTest, they could be simpler, which I suspect would make them even easier to adopt. To re-quote the Einsteinian edict: “A framework should make use of attributes to simplify developmental constructs, but it shouldn’t overuse them.” How’s that for overstating the obvious?
September 25th, 2007 at 12:17 pm
[…] The brains that brought you NUnit have decided to create a new and improved testing framework dubbed xUnit.net. Their goal is to learn from the lessons of NUnit, thus creating a more usable framework (for example, they realized you don’t need to attribute a class if you’ve used an attribute on a method!). […]