I completely agree. I'll use TDD when implementing a function "where the code is mostly self-contained with few external dependencies and the expected inputs an

I completely agree. I'll use TDD when implementing a function "where the code is mostly self-contained with few external dependencies and the expected inputs and outputs are well defined and known ahead of time" and where the function is complex enough that I'm uncertain about its correctness. Though I find I usually do property testing, or comparison to a baseline on random inputs, similar to the quicksort example in the blog post (against a slow, naive implementation of the function; or an older version of the function, if I'm refactoring) rather than straight TDD. When debugging, I'll also turn failure cases into unit tests and add them to the CI. The cost to write the test has already been paid in this case, so using them to catch regressions is all-upside. System tests are harder to do (since they require reasoning about the entire program rather than single functions) but in my experience are the most productive, in terms of catching the most bugs in least time. Certainly every minute spent writing a framework for mocking inputs into unit tests should probably have been spent on system testing instead.