Incorporating NUnit into the Culture


My team is taking a dedicated look at NUnit over the next week or so, in order to figure out how to incorporate it into the culture.

I feel sort of guilty spending so much dedicated time on this educational task, because I’m so used to spending my days firefighting, managing, and troubleshooting. But this should be part of an Architect’s job, so I’m trying to ignore this uncalled for guilt emotion.

We have two main motivations for investigating unit testing. One is the desire to decrease the number of bugs found during the QA process. The other is our move towards continuous integration. I’d love to eventually get to TDD, but that’s a longer term goal.

Also, although Visual Studio 2008 has built-in testing in most SKUs (as opposed to what VS 2005 did), we decided to go with the de facto standard of NUnit. Besides, I understand there’s an integration option for VS, anyway.

The initial questions we’ll be looking to answer is the following:

  1. Should we learn it by adding tests to existing systems?
  2. Should we just add it to new projects or to enhancements / fixes for existing projects? On this episode of .NET Rocks!, one suggestion was to assume that existing systems in production are clean, so just create tests when needed.
  3. Should we introduce mocking at this point? Or is it too much to tackle at the same time. But if not, how can we really be creating “unit” tests if we retain dependencies?
  4. Should we have the team work together on a single system so we can all learn together, or should the team start by learning from the NUnit samples and reading the definitive book on the subject?

One of the first things I did was google for how others are approaching this problem. I found a lot of articles, so I have a bunch of reading ahead of me.

I’ll be posting links to those, and whatever else I learn, in the upcoming days.


  1. To answer your questions directly:
    (1) If you have time, those who are exposed to the existing systems can do so. It can tend to be time consuming depending on the size and complexity of your overall system. Mocking objects are usually hand in hand with unit testing. It’s fairly simple as long as you already have interfaces in place and your system is prepped for loose coupling.
    (2) That’s a judgement call, although I agree with the article that you can assume existing production systems are clean, but to a certain extent – it can also be very helpful in finding bugs not yet found. I would think that it would only help instead of hurt.
    (3) Mocking is essential, but can be avoided – it all depends on how you want to integrate it overall and how your current system is architected. Is it loosely coupled or is it tightly integrated to external resources (db, networking, etc)
    (4) Depends on your team, you would know better each team member’s style and if it would benefit them to do it one way or another.

    *Note: You can use NUnit integrated into Visual Studio during your build process etc. – this the fully integrated way of doing it.
    or you can do it, the way I like to do it – where you have the TestFixture in your solution, etc. but not have it involved in the build process, just use NUnit to test your Unit Test Cases individually. In this latter scenario, you won’t be fully TDD, but well on your way to transitioning your team towards it.


Please enter your comment!
Please enter your name here