Two unit tests, zero integration tests
This is a scenario[^] I have discussed previously when discussing code coverage[^]. When you have two units of software, such as two functions, that work as expected when unit tested independently. The problem arises when those two functions interact with each other. This can sometimes produce entirely unexpected results. And this underscores the reason why integration tests are every bit as vital to the production of high quality software as having unit tests.
Without having integration tests, you won’t find out how the various pieces of software interact until they find their way into the end product. In which case you had better hope and pray your testing team finds them first. If they don’t, then you can bet your last dollar that your customers will, and that is the worst outcome of all.
The build for our ASP.NET Web API services has over 200 unit tests, but also many integration tests that ensure that the various pieces all work together. This is why having 100% code coverage is not enough. Testing the various pieces of software in isolation is not sufficient. You also need tests that will mimic how the functionality is invoked by the end user within the end product. If you don’t have such tests, then your testing coverage is quite simply inadequate.
When developing a new piece of software, you need to be mindful of how you intend to test it. This should not be an after thought, but something that you are conscious of during the entire life-cycle of the new piece of software. If you are using a TDD approach, then this will form part of your process of software development. It is usually more difficult to retro-fit a unit testing framework around your code after it has been written, than to do so from the very beginning. Even if not using a TDD approach, if you are in the habit of writing well designed software that adheres to the SOLID principles of software development, then applying a unit testing framework should provide fewer obstacles.
So by all means, have as many unit tests as your application requires, but also be mindful of how the various pieces of software will ultimately interact with each other in the real world when used by the end users.
Remember, If you’re not writing unit tests, you’re doing it wrong.
If this article was helpful to you, please do hit the 💚 button below. Thanks!
