NUnit and TDD – Fail First

by | Development | 5 comments

Between handling response issues, we’ve continued our NUnit exploration.

From what I’ve been reading, it appears that using NUnit without the intention of TDD is like using Visual Studio without enabling Intellisense. Why bother?

I started by reading a few articles, such as Getting started with TDD, by Steve Smith. I also read a good one by Roy Osherove, and he states in his Test-driven development with NUnit – Introduction article, there are three bulletpoints for doing TDD:

  1. Make a test that fails
  2. Make it work
  3. For every new feature, go to step 1

Now, that seems rather simple, but the hard part is figuring out what tests to write, and if you’re testing existing code, should you refactor it in order to enable proper testability.

The concept that seems to be hardest for people starting out in TDD to grasp is the whole concept of writing a test that fails even before attempting to write the code that implements the feature being tested. But if you think about it, it’s a pretty common iterative approach to things.

The first example in Roy’s article shows that you do this by trying to instantiate an object from an as-of-yet non-existent class. You can’t get much more basic than this. That’s an easy one to get to pass, and it’s a bit of a high getting that test to turn green. Now you feel like you’re on your way.


Roy’s article is a great intro, but the main goal I’m trying to accomplish is to decide HOW to introduce NUnit and TDD to a development team, so I’m continuing to research how other teams have done this.

We’ve answered our first two questions from the prior article , and decided not to learn by incorporating tests into our existing systems, mainly due to the comment made in my previous article that we need to assume that current systems are "clean".

Due to scheduling conflicts, we also answered question 4 (should we have the team work together on a single system so we can all learn together, etc.). We’re experimenting on our own with samples that come with NUnit, plus our own small examples. As we work on future projects, we’ll build on that by generating tests for new code, and creating tests for modified code. We also recognize that refactoring will probably be in order to make existing code more testable, so we have to be mindful of including this into our estimates. Convincing management shouldn’t be too difficult, since they already feel the pain of too many bugs getting into QA, and are realizing the up-front time investment is worth it.

We’re still discussing question 3, the introduction of mocking. We’re leaning towards building our own mock objects on an as-needed basis at first, and we’ll look at third party mocking tools later on.

We’ve also taken a look at TestDriven.net , which provides some basic integration into Visual Studio. The best part of this tool that we’ve seen so far is the included nCover utility, which helps us to see what code we may have missed writing tests for. The jury is still out for us on the entire TestDriven.net tool, since nCover is available separately, but some people swear by the whole package.

Well, on with my best practices investigation for introducing NUnit and TDD…