Getting a Fix on Fixie

My friend Patrick Lioi (@plioi) is writing Fixie, a testing framework, and I’m using it in one of my projects, a genogram generator (which I will write about once it does something interesting).

Why make a testing framework when we already have xUnit, NUnit, MbUnit…? Patrick has a few reasons, my favorite of which is: to learn what can be learned from writing a testing framework. Really, who needs more reason than that? He’s writing a great blog series about it, gathered up on Fixie’s project page.

Making the switch

Rolling it into my project was simple. In my case, it was also quick, because I didn’t yet have many tests. But even if I did, the steps are still simple to understand.

1. Put your tests into their own project.
2. Use NuGet to install Fixie and an assertion library, such as Should.
   And there’s one of the points that make this project interesting: Finding and executing tests really has nothing to do with assertions; therefore, Fixie doesn’t impose an assertion library on you. Use what you like.
3. If you’re using the default convention for discovering tests, clear all the clutter off your test classes and methods.
   Or you can define a convention to mimic your existing test framework, to make conversion easier.
   • The biggest NUnit-to-Fixie change I had to make is that, instead of a [SetUp] method, Fixie’s default convention uses the fixture class’s constructor for setup, and its IDisposable.Dispose() method for teardown. This has a definite advantage if you have inheritance amongst your test fixtures (not my favorite, but suit yourself): The order in which those constructors and disposers are called is well defined and free from surprises.
4. Run your tests using TestDriven.Net or the Fixie.Console included in its NuGet package.
5. Use NuGet to remove the old test framework.
   Whee!

Why use Fixie

Patrick would shoot me if I said it was ready for prime time. There’s lots to build yet. But I’m having fun using it in my small project for a bunch of reasons:

1. It inspires me to ask myself, what conventions would I like to use for test discovery and execution.
2. The ctor/IDispose pattern for setup/teardown is totally predictable.
   I once discovered, unpleasantly, that the ReSharper test runner and the NUnit console would run inherited [TestFixtureSetUp]s in different orders. That was… tough to track down.
3. Using conventions means my tests have much less cruft.
4. And I’m helping my friend, by putting his code to use. 🙂

Okay then, why read Fixie

Oh, now that, even if you’re not shopping for a new unit-testing framework, is worth your time. Patrick’s blog posts documenting the Fixie project—documenting the birth and design of an open-source project, really—are fun and insightful. (Still probably going to get shot. Ah, well.) Check ’em out.

Try something new

Sometimes the best help you can contribute to a fledgling open-source project is to be an enthusiastic early adopter. Use their framework to give them more examples of how it might be used, how another developer interprets their API, and what features would be most useful next.

Any projects you’d like to highlight here that would welcome some early adopters? Tell us about them!