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:
- Should we learn it by adding tests to existing systems?
- 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.
- 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?
- 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.