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!

Related Articles:

About Sharon Cichelli

I am a Headspring Senior Consultant, developing custom enterprise software for our clients and leading training classes on the latest Microsoft technologies. I blog about .NET development, best practices in agile software development, and my nerdy hobbies.
This entry was posted in Open-Source Software, unit testing. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Sean Feldman

    Is there anything special needed to get Fixie going with TD.NET?

    • Patrick Lioi

      The nuget package ( http://nuget.org/packages/Fixie/ ) includes the library itself, Fixie.dll, as well as the Fixie.Console.exe runner and the TD.NET support files. Your TD.NET shortcuts should work without any extra setup. (I suppose if your test project happens to also reference NUnit, TD.NET might have to pick a “winner” to run. When you run a test via TD.NET, you’ll know it worked if it says “Fixie (0.0.0.x)” in the output.)

      • scichelli

        In other words… no, nothing special. @seanfeldman:disqus, were you hitting a specific issue, or just asking out of curiosity? (I was curious, too. I didn’t expect it to _just work_, but it does.)

        • Sean Feldman

          Verifying. Used mspec, but people didn’t like it. We use xUnit currently, and it looks like Fixie is a better option for us. Some of us use R# to execute tests and some TD.NET (ok, just me). If we to go with Fixie, need to make sure at least one works (and yes, I’m happy it’s the one I happened to use :D )

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1376

  • Carlos Ribas

    So cool. I hate [TestFixtureSetup]. UGH, what a horrible design. Hey, Patrick, is there a provision for setup that is desired to be once per fixture instead of once per test case? Sometimes with integration tests there’s some overhead that we like to mitigate by (ugh) sharing a little state between test cases. It’s dirty, but if it runs tests 50x as fast, sometimes it is worth it.

    • Patrick Lioi

      Yes! The customization API is *very much* in its infancy, so the details will surely change, but I can already opt into one-instance-per-test-method as well as one-instance-per-test-class. The latest blog post includes an NUnit-like convention: http://www.headspring.com/dry-test-inheritance/ (see the part that says FixtureExecution.CreateInstancePerFixture( )). The idea is you could stick with the simpler convention for unit tests, and branch out into things like CreateInstancePerFixture( ) in integration tests. The next few blog posts will dig deeper into the integration testing side of things, specifically for IoC and things like database transactions.