Let me know if you’re getting tired of TDD-related content. I’m kind of getting tired of writing it but there’s still a lot of wrong out there.
The prompt was: “I don't like this notion that TDD alone is enough for an excellent system design to emerge”. tl;dr I agree. You have to make the design decisions. Here’s the reply in more detail.
Nobody with any sense says TDD replaces the need for design. The key question is *when*. You're suggesting a handful of implementation design decisions made before writing & passing the first test. That doesn't seem horrible to me, especially compared to the months-to-years-long design "phase" of yesteryear.
TDD offers:
Immediate feedback for interface design decisions. You still have to make those decisions. The design will only be as good as your decisions, but your pain will also be inversely proportional to the quality of your decisions.
Separation between interface design decisions & implementation design decisions. This was always recommended to me without anyone explaining how.
Once you've made & notated an interface decision as a test, you'll get immediate feedback whether or not your implementation design decisions pass the first, lowest bar--does the code work?
If you aren't confident about making implementation design decisions in the presence of interface design decisions, okay. Maybe experiment with just how few implementation design decisions you really need to make. I was curious what my minimum was. Turns out, experientially, the answer is zero. This is a number for your to find out for yourself.
I see value in the TDD content - as you say, there is still a lot of wrong out there. Explaining in different ways helps improve the likely hood of adoption or at least trying it.
> Let me know if you’re getting tired of TDD-related content.
Nope, I don't think I'll ever get tired of it!