> Most of my day-to-day coding is adding small bits here and there in the right place, discovering the architecture of the whole thing as I go. Without knowing

> Most of my day-to-day coding is adding small bits here and there in the right place, discovering the architecture of the whole thing as I go. Without knowing what I have to do to achieve the desired result in the first place, I cannot begin writing a test with the half dozen mocks it needs (I know it's bad). Nothing in your example prohibits or even hinders TDD. The only thing required by TDD is that you specify an interface and add tests to specify what behavior you expect from them. The moment you have something you can compile and run, your TDD path is completely open. Also, I'm noting the hints of the same specious reasoning that plagues discussions on microservices, mainly the "it's-all-or-nothing" fallacy. You can benefit from TDD if you, say, are writing a RESTful interface and start off by only adding unit tests checking for controller behavior. If your project can live with 0% line coverage, it can certainly live with TDD buying you 20% line coverage.