Fixie’s Elevator Pitch

I’ve been developing a .NET test framework, Fixie, over the last few months, documenting my progress each week on my old blog. The relevant posts are reachable via the Fixie github page. For my inaugural Los Techies post, I thought I’d catch everyone up with the elevator pitch. The elevator is in a fairly tall building.

First, I found myself favoring xUnit over NUnit, mainly for the brevity that it gives you as a result of its simpler test class lifecycle. When you get one instance of a test class for each test method, concepts like construction, [SetUp], and [TestFixtureSetUp] collapse into simple construction. Trading away boilerplate in order to use built-in language constructs like constructors feels right.

Next, I made a customization to xUnit which gave me even more brevity. Instead of having no attribute on my test classes but a [Fact] on each test method, I flipped it around so that I needed a [Facts] attribute on the test class and no attributes on each test method. Why bother repeatedly saying, “This method, which is obviously a test method, is in [Fact] a test method”?

However, xUnit’s means of customization proved a little frustrating. I had to work with a pretty big ISP violation, so big that I punted and threw NotImplementedException for the parts of the interface I really didn’t want to have to reinvent.

Also, the means of customization was still too opinionated about what a test class has to look like. In order to step in and say, “Hold on xUnit, I know what test methods look like, so just let me tell you what tests I found on this class,” I still had to use a special attribute on the test classes. Every test class I wrote had a name ending in “Tests” and an unfortunate [Facts] attribute as well. Why should I have to say the same thing twice?

I found myself wishing that NUnit and xUnit were less opinionated about test discovery as well as the test lifecycle. A test framework should focus on the boring parts: reflection, exception handling, and pass/fail counting. The rest should be exceptionally easy to customize.

With Fixie, you tell it what your test classes and test methods look like, and it uses those descriptions to go out and find them. Similarly, you can tell it how to perform the test class lifecycle: when and how to construct the test class, what to do before/after each test, and the like. By taking responsibilities away from the test framework, the end developer gains more degrees of freedom.

About Patrick Lioi

I am a Senior Consultant at Headspring in Austin, TX. I created the Parsley text parsing library and the Fixie test framework.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • ShortManDev

    Wikipedia: An elevator pitch, elevator speech, or elevator statement is a short summary used to quickly and simply define a person, profession, product, service, organization or event and its value proposition.[1]

    I could have gotten off the elevator before you’d even told me the name of your product. That said, i like the idea behind Fixie. integration with resharper would be huge though, especially now that resharper addins are easier to make and deploy using nuget.

    • Patrick Lioi

      ReSharper support is the most-requested feature, so I’ll be working on that in the not-too-distant future. Thanks for your interest!

      • ShortManDev

        great. i’d also be interested in knowing if you plan to support delegates for test methods, setups and tear downs. something like MSpec comes to mind.

        • Patrick Lioi

          MSpec-style raises some interesting questions. To date, I’ve gone on the assumption that tests are methods. With MSpec, tests come from somewhere else: *fields* that just happen to be of delegate types. So, at the moment, I don’t support that. I’m leaving your GitHub issue open while I noodle it over. The decision will boil down to whether or not I can support “tests come from anywhere, not just methods” without having to make the more widely-used “tests are methods” approach excessively complicated for the end user. Thanks for the request, I think it will make Fixie stronger in the long run.

    • Matt S.

      I consider his last paragraph the actual elevator pitch. The preceding content would follow after the person responded with, “Oh, that sounds really cool. What made you take on such a cool project?”.

      I just found out about this project via the Fubu guys. Looks really promising.

      • ShortManDev

        i get that vibe too, mainly just pointing out that the proper order is really important for an elevator pitch. If i didn’t already know what fixie was i may have become uninterested.

  • Matt S.

    I’ve been using AutoFixture quite a bit lately with xUnit. Are you familiar with it? Any opinions you’d care to share regarding its use with a test framework?

    One feature of AutoFixture coupled with xUnit I really started using to avoid ceremony is method parameters (via Theory) that are supplied by AutoFixture. This sounds very similar to some of your examples for supporting IoC.

    By having fewer opinions, I get the real sense that Fixie will let me do whatever I want with testing. That’s a good thing, because I’m constantly improving my workflow and changing things. With current frameworks, I’m very limited. A change in framework typically means a TON of changes to existing tests (if I were insane enough to make a change on an existing project). Fixie’s conventions let me keep my existing tests, while I write clean newer ones. Very cool!

    ReSharper integration would be phenomenal!

    • Patrick Lioi

      I haven’t used AutoFixture myself, but from the examples I’m looking at it does seem like its usage in Fixie would resemble the IoC example ( ) as you point out.

      You mention xUnit theories for supplying method parameters… Fixie doesn’t currently support test methods with parameters but I absolutely intend to support that. Like all the other hooks, it wouldn’t *have* to be done with xUnit-style attributes, if you want them to come from some more interesting ‘source’ like AutoFixture.

      I plan on ReSharper support once I knock out the nuts-and-bolts features like test method parameters.

      • Matt S.

        Patrick, I know where you hail from (as a programmer), so my next question won’t really be a surprise, and may even be rhetorical. Do you have *any* idea just how exciting this all sounds to a seasoned geek hearing your plans?

        I already dislike writing tests much less as a result of xUnit, Should, etc. However, something like this would just be an absolute no-brainer as the de facto choice for a .NET dev’s test framework. We may even start to like writing tests. It would really only come down to exposure at that point (i.e., “So, have you heard of Fixie?”).

        So, thanks for Fixie, and thanks for writing about your experiences while developing it. Seriously, man.

  • Guest

    I think it will still be good

  • I hope I will be able to approach it soon

  • yeah, successfully, I want you so much and I’d like to think so