Yeah, that advice was bad and looked like it was written by someone that's done too many deployments and not enough development.
He's certainly right that deployment validation is the best test at some level. But it completely leaves off the most important aspect. That deployment validation, and the mistakes that you inevitably find, should directly guide your test development to prevent regression.
If you do this, future component upgrades and deployments get easier. Its well worth the extra effort.
He's not discouraging automated testing; he's just saying that we should prefer integration tests (using services running locally) to unit tests of individual functions. Look up "testing trophy" for more about this philosophy.
Totally with you on the value of integration tests. I'm familiar with the trophy and the triangle, but he's saying this:
'..with unit tests notably coming in last place – i.e. “only if you have some time”.'
The "only if you have time" part is what I disagree with. If we're doing TDD then I don't see how you can avoid writing unit tests, or even deprioritize them.
> The "only if you have time" part is what I disagree with. If we're doing TDD then I don't see how you can avoid writing unit tests, or even deprioritize them.
Perhaps the author doesn't recommend TDD? They don't suggest anywhere that they do. It seems to me that the industry these days sees TDD as a tool for occasional use, not the dogma once proposed.
+1 unit tests are essential for software evolution like refactors, updating business logic, and updating dependencies. More generally, good testing requires a defense-in-depth strategy and unit testing, integration testing, and canary testing all have a role to play. All other things being equal, it's much better to catch a bug before you even push to the the source repo versus when it has one foot out the door to your customers.
Yeah as some of the responses to your reply said, agreed, and I've always found value in unit tests, and the "too many deployments and not enough development" comment from jsight rings loud in my head. Deploying to a real non-prod environment as a "test" can be fine for a team, but to do so while not testing for how you expect the code to behave... maybe that works for some folks and if you're moving super fast, but I wouldn't be super comfortable with it myself.
I totally disagree with the author on testing. Integration tests are more trouble than they are worth in my experience, and unit tests are really useful.
