Over the last few weeks, I’ve implemented some customization features in the Fixie test framework. The first of these features is now available. Today, we’ll see this feature in action. We’re going to tell Fixie what our tests look like, and Fixie will then find them and run them. Today’s code samples work against Fixie 0.0.1.49. The customization API is in its infancy, and is likely to change as I address more involved features in the coming weeks. The Default Convention If you’ve used NUnit before, you know that you have to mark your test classes with [TestFixture] and your test methods with [Test] in order for NUnit to know that those are your tests. NUnit uses the presence of those attributes to “discover” your tests before it can run them. NUnit is therefore opinionated about test discovery. If you’ve used xUnit before, you know that you have to mark [...]
Enabling Change
Unit testing is meant to enable change by giving you confidence about the current state of your project. However, one of the criticisms of unit testing is that fine-grained tests (such as having one or more tests per method), locks you into implementation details. With fine-grained tests in place, you’re not free to move responsibilities between methods and between classes. How are we to resolve this apparent contradiction? I do lean towards fine-grained tests, especially in the early days of a project. At that point, small implementation details are all you’ve got. As a project grows and evolves, that early “scaffolding” of fine-grained tests may start to become an obstacle rather a change-enabler. Test frameworks are tools meant to give us the freedom to change, but we must deliberately wield them to enable that change. When your fine-grained tests start to discourage change, introduce new tests at a higher level, [...]