It’s not often that I write a blog post simply to call attention to another spot on the site, but that’s what I’m doing in this case. We’ve just added a new resource to address some of the practical implications of trying to unit test. There are lots of sites out there to get you unit test theory, so we’ve stuck to a quick overview and then jump into a simple example which can help you see how to overcome some of the most common issues with trying to effectively unit test.
Why write this? Doesn’t everyone know how to unit test already? Unfortunately not. We find that teams often confuse integration testing done by the developer to be unit testing. There’s nothing wrong with integration testing – far from it – but unit testing, done properly, is looking for a different kind of defect. These defects – null pointer exceptions, off-by-one errors, etc. – are harder to find through traditional functional testing, leaving a clear gap in your test coverage.
More importantly, you often want to integrate unit testing into your teams’ existing practices, but that means they’ve got code which isn’t necessarily perfectly suited for unit testing. We believe this short tutorial will help you see how to resolve those issues so that you and your team don’t get into an ideological battle. Instead of “we can’t unit test because the code isn’t structured for it” (but full well knowing the code will *never* get restructured for it), help your team unit test as effectively as possible even in an imperfect world.