Test SetUp Methods, or "How to make yourself public"

Here’s a little sidebar that I bet you didn’t know. Actually, that was probably more accurate at my old site where my readership measured on a more, shall we say, intimate, scale.

Anyway, I recently converted a project from NUnit to MbUnit just because I felt like it. (Oh, I’m kidding. I have reasons. Boring but valid ones. So don’t sic the alt.net police on me.) In the past, that has involved adding the assembly reference for MbUnit, then performing a global search and replace of the appropriate using statement. Perhaps cleaning up the different Assert syntax but in general, it’s a pretty painless process.

This time, I got null reference errors in all tests in several class and to make a long story short (don’t get used to it, I don’t do it often), I traced it to the SetUp method:

    [ SetUp ]
    protected void SetUp( )
    {
        // Do stuff
    }

Notice that it is protected, which apparently makes it all but invisible to MbUnit. I switched it to public and my world is fully tested again.

Initially, I thought it might be worthy of a bug report. But here is kind of what I typed out:

Hey dudes! You got yerself a fine ‘n dandy little product here. But I got meself some tests here someone was nice enough to write out for me in NUnit and when I converted them to MbUnit, they done gone failed on me ’cause the SetUp method is protected even though… the tests themselves are…ummm… y’know…public…

Here’s where I started to feel a little silly and considered that maybe the MbUnit folks knew what they’re doing when they wrote the product (although I wouldn’t mind it handling nullable types a little differently).

So I guess I don’t really make this long story all that shorter. The Hillbilly is nothing if not contradictory.

Kyle the Taciturn

This entry was posted in Refactoring, TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/blogs/kyle.baley Kyle Baley

    I’d go along with Jeff on this. If it’s conceptually wrong, then that’s reason enough not to support it. But as he mentioned, if you can make a case for it, which I clearly cannot in this case since my reason is “the previous team made the setup method protected by accident”, then it sounds like they’re amenable to adding the feature in.

  • http://blog.bits-in-motion.com/ Jeff Brown

    We’ve considered supporting non-public setup methods, tests, and other things before. Code-wise, it’s a tiny change. I’m more concerned about making sure this is really a practice we would like to support / encourage.

    The basic assumption is that anything you want the test framework to see should be exposed to it, publicly.

    However, if you can make a good case for different behavior, then I encourage you to file a request for enhancement over here: http://code.google.com/p/mb-unit/issues/list

    (And you’ll probably get your wish in the MbUnit v3 timeframe.)

    Cheers!

  • http://blog.dotnetwiki.org Jonathan de Halleux

    You should simply report that as a bug to mbunit. There’s no reason why they won’t not support protected setup method (although it’s conceptually wrong).