Answer to a comment by Jeremy Gray has started getting really long, so I’m putting the primary idea in a separate post.
As we all know, NUnit is one of the first unit testing frameworks for .NET. It is old, stable and quite conservative. At the same time, it’s feature set is inferior to the functionality provided by some newer frameworks (or even frameworks for handling unit testing frameworks, like Gallio).
However, I’m still trying to stick to NUnit in my projects. Reasons for that are:
- It does not make reading tests challenging for new devs (unit tests are normally point of entry into the code, if they are present)
- Unit tests are often considered to be usage samples for the code they test. We’d prefer to keep these simple, would not we?
- The most important reason for me: simple unit testing framework forces developer to write unit tests that are easily testable (just like TDD forces some good logical separation between the components)
Imagine some really complex method that accepts quite a number of arguments and performs some black-box magic inside. If you have a data-driven unit testing framework at hand, you can simply create CSV file with valid entries and test this method against that. But if you do not have this functionality at hand, then you’d need to refactor the method to make it more simple and testable.
I like the last scenario. Even if it is not fun at the very start, it does pay off in the long term.
Err, i’m not quite sure how MbUnit would violate your reasons for sticking with NUnit, unless you are especially sensitive to changing using statements and like working with a smaller set of assertions. :)
On a more serious side, having just worked on two projects simultaneously, one using NUnit, the other using MbUnit Gallio, I can say this: The lack of standardized, well-supported row testing functionality in NUnit dramatically increases the noise in test classes. Being able to use row tests where appropriate makes test code unbelievably more clear. And that’s just when looking at the row test functionality, let alone when considering things like MbUnit 3’s new mechanisms for easily verifying multiple implementations of a given contract, for example.
I still love NUnit, don’t get me wrong, but I do consider myself an MbUnit/Gallio convert and will not only be migrating my current client’s project to it (while wishing I had started the project with it) I will be taking new projects straight to MbUnit/Gallio.
Jeremy,
Thank you for the feedback. Chances are, that I’m just being conservative about NUnit here (just like I’ve been about NHib or Boo).
I did try to jump into the MBUnit before, for its rich feature set. It allowed (encouraged) me to write more complex code, that could still be easily tested. The tests themselves got low-noise but really diverse in the approaches.
And that was not good - I believe the code and the tests have to be boring and simple))