It's unfortunate that TDD is always framed in terms of adding fully-automated unit tests to the test suite. That's a big commitment! The core proposition of TDD is that you should explicitly state what you're trying to accomplish before you code - then use empirical observations of running code to confirm your progress. Ossifying your API into the unit test suite is not the only way to accomplish it!

There are lighter tools that help you establish an assertion, run it (failure), code it, run it, repeat until success and only then solidify the API into automated tests. CLIs, shell scripting, browser tools, etc can be a powerful tool to build semi-manual acceptance tests that confirm that the whole thing works properly BEFORE committing to a particular implementation. And when in doubt, write integration tests that hit the public interface, not the internals.

>TDD requires you to commit to an API before you fully understand what you want from it.

Unless you're running a spike that's actually a good idea.

TDD doesnt force a complete commitment, but by forcing you into a semi-commitment to your API before building it it often ends up drawing out questions and critical assumptions about the API design which helps prevent a lot of design and requirements mistakes up front. It's an instance of shift left - "testing" your api before even writing a line of code.

So, what youve characterized as a bad thing is actually a very good thing, provided you're TDD'ing at a high level.

Short piece, makes a reasonable point: TDD has its place in the software development lifecycle, it’s not always the best approach for every situation but kind-of spoiled by the click-bait title contrary to that point.