Pragmatic Unit Tests

I am preparing a Slide Deck on Unit Testing for my employer’s .NET User Group.  The deck is pretty vanilla but it does help me crystallize my thoughts around dogmatic versus pragmatic unit tests.  The purist argues that the unit test should be in complete isolation – it has no dependencies across layers and, therefore, needs a mocking framework to be used correctly.  I take a more pragmatic approach – I am less worried about writing correct unit tests as much as writing effective unit tests.

I recently added some unit testing to a project for which I am tech lead.  We implemented some unit tests that call an API that, in turn, calls a lower layer.  The tests are clean and they are very effective at identifying problems when the code changes.  Interesting, even though the unit test depends on some data in a database – they have yet to fail because of that dependency.  It has failed for some failed logic introduced when refactoring though – proving the usefulness of the tests. If the tests do fail, the developers know that the error might be in the dependency and can investigate appropriately.

 I think this example points to the heart of the unit testing – you either take ownership and use them effectively as part of the way you code, or you don’t.  If you are in the former category, you can get away with dependencies in your unit tests.  If you are in the latter category, you shouldn’t even bother with unit tests at all – correctly formed or otherwise.