This works for me: testing is about sustainability. If your tests don’t let you be sustainable (for whatever value of “sustainable” is
important to you) then you’re probably doing something wrong.
The interesting thing here is that you can define sustainability as “if we don’t have this live tomorrow morning, the company will fold” and then proceed with the most appropriate testing strategy – something that gets out of the way and gives you the fastest possible feedback, like a smoke test not much deeper than a ping to the server or a wget piping to diff.
If you define “sustainable” to be “this codebase needs to constantly adapt to new features and output formats over the next 5 years”, the testing strategy changes accordingly, and it is up to a team of competent professionals to choose at what level to operate. In this case, most would choose to use tools like Behaviour Driven Development/Design and Domain Driven Design to explore as much of the problem space as possible during development and seek shared understanding through automated and repeatable processes, that can be maintained along with the codebase and ensure the features are always easy to understand and modify, should the functionality require changes (and it will).