Where I work we’ve have been ideologically on board with writing more tests and we’ve been consistently committed to “doing better” with testing for a long time, but we’ve also consistently not made the kind of headway on that goal that we’ve wanted to for a looooonng time. There are so very many reasons for this, and some of the important ones are probably organizational. I am not going to get into that side of things, rather I am posting this because I perceive it is a somewhat common problem, and I have a thought on one facet of it spurred on by a recent discussion with coworkers where the testing pyramid was brought up.
So, my thought is, in spite of genuinely agreeing that testing is good, we (as developers) intuitively see most of the tools we have for doing unit tests as having fairly limited value compared to the amount of work it takes to write and maintain them. In other words the value proposition just isn’t there! An additional unfortunate consequence of this pyramid mental model is that if you aren’t getting the unit tests done then items that seem to depend on those also get neglected - a kind of why build walls with no foundation cascade - which makes sense; if the mental model is correct, that is! But clearly it is NOT! Integration or end to end tests have immense value in our case that value would not be diminished at all even if we had absolutely no unit tests! The pyramid is wrong - just fundamentally incorrect in that sense in our case at least! There is a trophy analogy that I think is an improvement.
So no to tests then?! No! Not saying to throw out baby with bath water, of course. Thou shall not yeet babies! The value of tests is not even something I am questioning, just the relative value of unit tests compared with other tests. That “unit” tests (if we could even agree what that is…) being the foundation of a testing hierarchy might be a mistake that steers us, me, people, dev teams generally, away from actually adhering to a discipline of having good testing coverage on code. Confidence in your code, and code you can be confident in over the long haul is achievable in other ways depending on the type of software you are writing. Some projects might be best served by fewer unit tests, more (and easier to write/run) integration tests, built on a foundation of stronger typing or other language level safegaurds. My conclusion loosely held? Figure out the mix that works for your project. Find the best value per effort options given the testing tools in the stack you are working with and invest in those rather than trying to dogmatically fit to some pyramid, trophy, saucer, pizza, or whatever.
UPDATE: I watched a talk today about “The Testing Shapes” slides here and one of the great takeaways for me was the testing matrix.
By replacing the speed and cost axises with confidence and effort I think it leads to a much less dogmatic approach to testing.