I feel like this is a case of one of those "movements" that is just "Yes, under certain circumstances this might be a good idea; and under others, it won't be". Consider that tests are literally executable specifications of how the system or component should behave (a formulation I associate with Dan North, but I'm sure the idea is far from original). Now the question becomes "should you write a spec every time before you start implementation"? It seems obvious that the answer to that rather depends on how well you actually understand the problem space you're trying to solve.
And if all the work you're doing is well understood before you start, I suggest finding somewhere your manager you with the hard stuff.
> It seems obvious that the answer to that rather depends on how well you actually understand the problem space you're trying to solve.
An advocate for TDD (as in “red > green > refactor”) might say that writing the spec upfront is an excellent way to understand the problem space, or at least to help achieve that understanding.
At least when I’ve been fortunate enough to work on projects where such a TDD approach is possible, I’ve found that to be the case. I’ve also often found it harder to gain that understanding when testing lags development.
And if all the work you're doing is well understood before you start, I suggest finding somewhere your manager you with the hard stuff.