Over the last two weeks, we’ve seen how Fixie can be configured to mimic NUnit and to mimic xUnit. That’s a neat little trick, but doesn’t provide much value. This week, we’ll see how Fixie’s convention API can be used to improve upon NUnit. Today’s code samples work against Fixie 0.0.1.62. The customization API is in its infancy, and is likely to change in the coming weeks. Today’s sample convention addresses two problems in NUnit: Lifecycle attributes are redundant Test class inheritance is needlessly complex. NUnit Lifecycle Attributes Are Redundant If you use NUnit, you probably see a lot of test classes like this: My [SetUp] methods are always named “SetUp”, my [TearDown] methods are always named “TearDown”, etc. It’s annoying to sacrifice whole lines to that noise. When 99% of your test fixtures use naming conventions like mine, the attributes stop telling you something. These attributes start to fill…
Read More

Last week, we saw how to define an NUnit-imitating convention with the Fixie test framework: when the custom Convention class was present in our test project, the default rules for finding and running tests were replaced, allowing us to write test classes with a familiar NUnit class lifecycle. This week, we’ll see how to customize Fixie to imitate the xUnit lifecycle. Today’s code samples work against Fixie 0.0.1.56. The customization API is in its infancy, and is likely to change in the coming weeks. Review: The NUnit Lifecycle With NUnit, one instance of your [TestFixture] class is constructed, and that instance is shared across all of that class’s [Test] methods. Test discovery is based on the presence of these attributes. You can identify methods as [SetUp] and [TearDown] in order to run common code before and after each individual test. You can also identify methods as [TestFixtureSetUp] and [TestFixtureTearDown], in…
Read More