Personally, I've found automation testing of any kind (unit, integration, God forbid UI) is the biggest waste of time in modern software engineering practices. I've never, not once in nearing 20 years of professional software development in companies big and small, well-known and not, have ever seen it be worth the monumental amount of time they waste.
I could go on and on about this but damn just feels good to "say" aloud.
In my experience, tests help me refactor stuff and detect when I have broken some expected inplementation.
For example, I was refactoring a SQL query builder and tests told me my JOINs where no longer containing ON clause. Might seem trivial but multiply this by a large codebase and benefits increase.
Another thing is that when I write functions with tests in mind, they tend to be more maintenable and simpler because it's hard to test functions that to a ton of things and have many side effects.
So you are saying that test driven development is: a) not useful for you and your use cases b) never useful in any use cases c) sometimes useful but not for you
Sounds like you had to maintain tests with the wrong kind of coverage. IMO there is an art to crafting tests that are economical.
They should cover core features that pay for the business, ideally as coarsely as practical. Some coupling with the implementation is inevitable, so I prefer it be at the highest level that can be maintained.
Have you never seen tests catch bugs that otherwise would have gone into production?
"In X years .." is the surest sign of complacency, overconfidence, and excuses on the path towards hubris. And the "I've never needed a seatbelt before" fallacy is a really terrible habit.
There is nuance between Cucumber bureaucracy, and proper testing practices that check real bits.
Superficial article waxing vague nonsense like "clean", which is meaningless.
Necessary and sufficient tests are essential, otherwise code is of limited value. At a minimum, unit test complicated bits and integration test the big, common uses. Add tests for fixed bugs to never repeat them. Without tests, refactoring becomes really risky and damn hard. For extra confidence: benchmark, fuzz, and property test, and sometimes consider formal methods like theorem-proving to validate behavior falls within bounds where applicable. It's easy to go overboard on process or act as a cowboy coder who doesn't do things properly.