Test coverage, unit tests, and the test pyramid are non-negotiable
Everything is negotiable, but...
This is one post in a series of posts in response to this post. If you want more organization around my response as a whole, start here.
Alves disagrees with a full test pyramid is non-negotiable. That’s fine with me. Everything is negotiable. Whereas my default is a full test pyramid, I don’t insist on absolutes everywhere I work.
However, he quickly becomes an absolutist: he wants to scale down unit testing just to core business logic and remove end-to-end testing.
I disagree with this precisely because I believe everything is negotiable, and he’s erring on the side of absolutism.
For example: In working in implementations for a B2B SaaS startup, you can’t skip end-to-end testing and then just hope feature flags are going to save you. There’s a roll out-date, and if your system crashes and burns, you’ll lose an anchor client.
Another example: There are situations where I might be inclined to listen to Alves’s recommendation, such as quick feature rollouts in a B2C, in which the feature will only affect a handful of users, can be reverted instantaneously while honoring change control, and the business is okay with the risk of frustrating those users— taking more time to roll out the feature.
I recently discussed QA as a part of engineering with a friend. I don’t insist on TDD, but I want an engineer always to know how to test his or her or their software as it is created— the logical next step is to test it. I also believe in test coverage, unit tests, and the test pyramid as parts of code review, as ways of demonstrating quality in KPIs, and important to customer-centricity. However, as into a traditional view of testing [unit tests, system integration tests, user acceptance testing, performance/load testing, etc.], I don’t walk into a business with an absolute plan, nor do I refuse to listen if someone recommends another approach.
Everything is driven by cost/benefit: sticking within cost budget, time budget, and risk tolerance.
I start the conversation knowing a boilerplate testing strategy with all the trimmings I know of, and I pare it back and make adjustments based on the scenario.
So my hard disagreement isn’t that Alves’s take on testing doesn’t work somewhere, it is because Alves’s take on testing doesn’t work everywhere.
There is no need to be absolute about a testing methodology when you walk into a discussion knowing all the tools of a testing strategy and being able to tune the approach for the business cost budget, time budget, and risk tolerance.