Robert C. Martin’s talks were mostly targeted towards an audience that needed convincing that it makes sense to write code for testing. He probably should have made it more clear that there is much more to effective testing than what he proposed - which is just the starting point, not the destination.
The issue with the TDD antagonism is that it is often used to let the pendulum swing too far the other way, serving as an excuse to bypass necessary testing effort, usually as a means to achieve a deceptively short “time-to-initial-success”.
Coplien’s Why Most Unit Testing is Waste doesn’t propose to stop testing. And the reference to “Waste” is a bit clickbait-ty - as he acknowledges that a lot of test code simply has a “best before date” - i.e. it is up to the developer to recognize when tests are no longer helpful and take responsibility to discard them.
Ian Cooper puts it more succintly:
Test the behaviour of the “public API” - not the implementation details; and tests being used to discover a suitable implementation need to be deleted.
be it red green refactor
The issue is training which oversimplifies it to “red green”, skipping the refactor step entirely.
Chad Fowler’s “tests are a design smell” is based on the observation that good tests can only exist if you have
- optimal boundaries with APIs that do not expose implementation details
- tests that verify the operational protocol against that API/boundary and not the implementation details inside the boundary.
The elephant in the room is the effective tests require optimal boundaries, boundaries which may take some time to discover. Given that it is often inconvenient to manage and minimized dependencies, appropriate boundaries are often not made a priority, leaving tests to be coupled to implementation details which can significantly add to the maintenance burden.
