There's been a recent resurgence on twitter and the like about how teams     should divide up their testing efforts. In particular, Tim Bray argues

On the Diverse And Fantastical Shapes of Testing

submited by
Style Pass
2021-06-30 10:30:06

There's been a recent resurgence on twitter and the like about how teams should divide up their testing efforts. In particular, Tim Bray argues compellingly in favor of taking automated testing seriously. Anyone familiar with my writing will know that I'm very much in agreement with him.

The point of these images is to indicate the amount of effort we should expend on various types of tests, in particular the balance between unit and broader tests. The pyramid argues that you should have most testing done as unit tests, the honeycomb and trophy instead say you should have a relatively small amount of unit tests and focus mostly on integration tests.

The second biggest issue I have with this discussion is that it's rendered opaque by the fact that it's not clear what people see as the difference between unit and integration tests.

The terms “unit test” and “integration test” have always been rather murky, even by the slippery standards of most software terminology. As I originally understood it, they were primarily an organizational issue. Let's go back to the days of large waterfall software projects. I'm working on a hunk of code for several months. I may be working on it alone, or in a small team. Either way I think of this hunk as a conceptual unit which we can work on in relative separation from its neighbors. Once we've finished coding it we can hand it off to the unit testing team, who then test that unit on its own. After a month or two to make those tests work, we can then integrate it with its neighbors and carry out integration tests against a larger part of the system, or indeed the entire system. The key distinction is that the unit tests test my/our code in isolation while integration tests how our code works with code developed separately.

Leave a Comment