I came into this thinking initially when I read the late Pieter Hintjen’s books. He was against numbers/coverage percentage and said that testing should be focused on APIs. This ensures that the components that works and ignores how individual components function on their own. And also results in less tests with a broad API coverage. He puts what he says into practice and as you can see, ZeroMQ has quite a low “coverage percentage” of around 60% (it used to be that low).
With my recent reading of “Continuous Delivery”, things seem to point towards focusing on integration testing. And it also mentioned about treating our software as a blackbox, giving it input and expecting correct outputs. Of course, failure modes or unhappy paths should be tested too. But it never explicitly stated that we shouldn’t do unit tests, just that we should only write tests for things that are repeated (expected input, expected output).
Does unit tests even matter anymore? Do they just simply cost too much, and that only integration and acceptance tests matter?
I too, feel and think that we should just cover APIs and not cover individual components. To me, individual components might change quite often and even functionalities/requirements might change sometimes, resulting in even more changes in the individual components. Writing tests for individual components that change often is costly. The costs just seem too much to be bothered and we should just focus on getting the right output from some input. Perhaps this is because I deal mostly with high level programming languages or web.
What do you think? Am I wrong or do you think so too?
