Pragmatic Unit Testing by Andrew Hunt, David Thomas, Matt Hargett

I started using NUnit a few months ago.  The concept seems simple and the documentation from the website is plenty readable, so I found it easy to begin working with it.  But in the absence of  seeing or talking to another person who uses NUnit (or JUnit or the equivalent), I wondered to myself, have I grasped the essential concepts?  Am I missing anything?  Pragmatic Unit Testing In C# with NUnit gives the reassuring answer that yes, NUnit is as straightforward as it appears and yes, I am missing some things .

The basic concepts that I had already figured out are:

  • Write short, simple tests. 
  • Put the tests in a separate dll
  • Tests should be standalone because you aren’t guaranteed what order the tests will run in.  Also because sometimes you just want to run a single test, not the entire suite.
  • You can write Setup and TearDown functions to run before and after the tests.
  • The process of writing code with unit testing in mind helps improve, refine, and structure the code.  So, there is a benefit that occurs outside of running the tests themselves.

Some concepts I missed are:

  • You can create and assign Categories to tests.  For instance, you might have Category Fast tests that you run all the time, and Category Slow tests that you run once a day.
  • You can include the NUnit dlls as part of your sourcecode tree (for example, a lib/NUnit branch).  This way everyone runs the same version of NUnit and you have the correct project reference path.  This is as opposed to making everyone have NUnit stored in the same global directory on their PC.
  • You should include test for “invariants”, which are conditions about the data that should always be true.  For instance, if a list should always be sorted, then include a check for that in your tests.
  • They raised – and answered – this interesting question:  Do the unit tests need to test for valid and invalid parameters?  The answer is that as part of your original design, you should decide where the parameters are going to get validated.  Everywhere?  That’s rather redundant.  Perhaps just the boundary conditions?  Make that decision first.  Then, those parts of your code that are responsible for testing for valid parameters should be tested.  For other parts of the code, you can assume that the parameters are valid. 
  • Mocking/faking/stubbing – I haven’t had to deal with this yet, but it’s in the book.

Since I am talking about unit testing here, I am going to throw in an item that wasn’t discussed in this book, but was part of an interesting podcast interview on se-radio.  Gerard Meszaros recommends that you do NOT start your first attempts at unit testing on legacy code.  It is one of the hardest things to unit test, since it wasn’t designed for it.  Instead, start with new code and design the code with unit testing in mind.  For legacy code, plan to refactor and write unit tests for the code when you start tinkering with it for other reasons.


Post a Comment

Required fields are marked *

%d bloggers like this: