Recent searches
Search options
#TDD doesn't produce designs, good or bad.
If you see statements like:
"TDD produces a design based on indirections. Much more complex than what could be otherwise."
Without some kind of examples, e.g., video of the process that demonstrates it, it's a meaningless and useless statement.
Humans design code, and in TDD they can use the feedback from Red-Green-Refactor to make decisions. The decisions are design, not the mechanism (TDD).
@jitterted I'm not sure I fully agree. I think #TDD lends itself to #emergentDesign by deferring design decisions to the last responsible moment.
@todd_a_jacobs @jitterted but "deferring decisions" still is done by humans. I'd say, at most TDD enables a design.
How do you find that TDD then "creates" the design?
@berkes @jitterted I'm saying it supports EMERGENT design. An emergent design is one that grows organically, such as when you follow the red-green-refactor pattern rather than big, upfront design, e.g. #BUFD.
Absolutely #TDD supports good design!
I still see people saying TDD "forces" good design, or bad design (depending on their agenda), and I'm trying to push back against that.
It's a tool, that I find extremely helpful for adaptive and emergent design, but it's a tool that still requires some sense of what "good design" is.
I've done "good design" before I went 100% TDD, though I wouldn't do that again if I had a choice.
#TDD is a great tool for surfacing design issues, but if you can't see what it's showing you, or ignore it, then you might create "bad" designs.
At least you'll have tests for the code you have? But if you ignore coupling, then they may be overly tied to implementation, which will make refactoring difficult.