Book Review - Pragmatic Unit Testing in C# with NUnit

Last week I allocated some time to work on our go forward strategy as it relates to our formal test plan. I have been wanting to put together a documented process on what the development team must continue to work on to increase code quality across the board while at the same time providing an automated framework of testing for the QA team to work with and monitor. As I have mentioned previously on my blog I have taken more and more interest in unit testing over the last year. As I was studying the process of extreme programming I realized it wasn't right for me, but that many of the aspects were still quite appealing. Unit testing makes a lot of sense, but I have found it difficult to find materials discussing how to approach it on an existing code base. It's all nice and dandy to talk about adding tests before or concurrently as you write production code, but how do you integrate unit testing AFTER you have written 10's of thousands of lines of code?

Well, I found out while reading Pragmatic Unit Testing in C# with NUnit, written by Andy Hunt and Dave Thomas. This is a no nonsense book which quite frankly was refreshing. There was no harping about the benefits of extreme programming and was focused completely on developer-centric unit testing... getting to the meat of HOW to test methods within your code. If you do not have a lot of experience in unit testing, this book is for you. And should be read before you tackle something like Test-Driven Development in Microsoft .NET.

The book cleared up a LOT of mis-information that many of the articles I have been reading up on. Now fully understanding how we can use things like mock objects to represent network and database failures, the topic was not only interesting to me, but critically important in understanding how to write USEFUL unit tests, and not just fluff. In other words, we can do more than just test arithmetic type methods and get into real world code being used.

And more importantly, it taught me how to tackle my code base. One test at a time. Each time I work on a new bug, I can write the unit tests for the methods relating to it. Over time, the critical areas which have the most problems will not only be refactored enough to work with unit testing, will have the complete harness already in place. One method at a time. Seems so simple doesn't it? Not so daunting when you look at it this way. I don't know why so many texts on the subject miss that.

The book also helps to explain how to design your projects so you don't have test code lying around hap-hazardly. It shows the right way to set up your test projects, and gives drawbacks and benefits with different approachs.

Of course the book is focused on NUnit and C#, but the theory and logic is just as useful in pretty much any language you use. I will admit seeing NUnit in action with C# all through the book made it extremely easy to understand the examples and write my own inital tests. I think I am going to have a lot more difficulty figuring out how to do unit testing with my kernel code in C. I have been looking at CuTest but the example tests in the README seem weak compared to what I see in NUnit. Time will tell if I can find a similar library for my kernel drivers.

The book is a light read (about 150 pages), done in just a couple of hours. I have spent more time trying the examples and writing my own initial tests to see how effective it was. Over all a great introduction to unit testing that makes sense. And it has convinced me to start adding unit tests to our C# code immediately, the next time we fix a bug or add new code.

Of course now it adds an entirely new can of worms to our automated build environment. Never fear, the next book in the series is on how to do just that... called Project Automation. Looks like I will have to add that to my list of technical reading.

Anyways, good book that was easy to read and understand. Well worth the money. If it even increases the quality of your code by finding one bug through the tests it pays for itself. And that pretty much sums it up for me. If you are a professional developer not using unit testing you owe it to yourself to go through this book. You might be pleasantly suprised.

Enjoy.