Does TDD really lead to good design?

Skip to first unread message

Josue Barbosa dos Santos

Aug 25, 2016, 7:49:42 AM8/25/16
Hello all,

In the  following video theres is a talk from Sandro Mancuso. Don't panic about the title:) . He loves TDD and so do I but I think he makes good points. 

The video also have a good explanation (I think) of the classic and mockist approach to TDD. And I think he favors the mockist and explains why.

And the link to the blog post related to the video.

And other videos:

Does TDD really lead to good design?

“TDD is a design tool.” That’s what I’ve said for years. But not anymore. After working with different teams in different organisations, I realised that I don’t believe anymore that TDD is a design tool. In this talk I’ll be explaining the pros and cons of the two main styles of TDD, discuss why some developers can test-drive well-crafted code while others can’t, and also explain how to reason about design decisions.

For more about the differences between TDD styles, please check Sandro's blog post Does TDD really lead to good design?"
Message has been deleted

philip schwarz

Aug 25, 2016, 6:50:26 PM8/25/16
to Growing Object-Oriented Software

FWIW, some tweets (back in October) in which I transcribed excerpts from the first part of the video:

‏@philip_schwarz "TDD is not a design tool...there is zero prescription in the 'refactor' step of TDD" -

@philip_schwarz "What are the 2 main styles of TDD?...The 2 schools are not opposites...u can mix & match" - 

@philip_schwarz #GOOS start @ the periphery of the sys & work in.  I start in the center of the sys & work out @unclebobmartin #TDD 

@philip_schwarz in the classicist approach,the unit under test may become bigger...use refactoring 2 extract

@philip_schwarz @philip_schwarz related 2 unit under test growing:@ICooper in TDD,where did it all go wrong? 

@philip_schwarz  classicist approach designs according 2 feedback from code+normally minimises upfront design

@philip_schwarz I use the classicist approach when I don't have a proper domain e.g. when doing an algorithm

George Dinwiddie

Aug 28, 2016, 12:11:32 PM8/28/16
> <>"

The title is a question, but your post reads like a statement. I'm left
unsure whether you're seeking a dialog or you're trying to drum up
viewers for these videos.

In the hopes that you're seeking a dialog, I'm replying. I haven't
watched any of the videos, but I took a look at the blog post. I think
it misses the point of what a "tool" is. A tool is not magic. It does
not guarantee a good result regardless of the skill and application of
the wielder. A hammer is a carpentry tool though it can sure make a mess
of things in the wrong hands.

Sandro says, "TDD becomes much easier when we understand what good
design looks like." That's certainly true, but the converse,
"Understanding what good design looks like becomes much easier when we
TDD" is also true. Practicing TDD well lets us consider what is good
design on a frequent basis, with a practical example at hand.

While it's true that every refactoring has an equal and opposite
refactoring that undoes it, TDD provides a gentle nudge in a beneficial
direction. If we understand good design to be that which is more easily
adaptable, then TDD gives every unit we test drive a second client from
the very beginning--the client in the production code and the client in
the test. This encourages us to consider reuse very specifically rather
than in a vague general sense.

I'm not sure of the purpose of this blog post. Why would Sandro care
whether or not TDD is a design tool or, as he calls it, a workflow?

I see a problem when he says "We are going from BDUF (Big Design Up
Front) to no design at all." When I TDD, it's not like that.

I went from BDUF to considering the big design throughout the
development. Sometimes I start with a mental image of 3 or 4 basic
components and how they'll interact (BDUF, but not detailed or
complete), and other times I'll start with a single component and
extract these big pieces as I go. Even when I start with an idea of the
big picture, I sometimes end up with a different big picture. And even
after I've gone a considerable way toward a design, I sometimes find a
better design is revealing itself and I refactor toward that one.

Using TDD has taught me the fluidity of code design, and gives me the
support tools to make it fluid without pain. Using TDD has given me the
confidence that when I find design constraints, I can modify the design
around those constraints. That confidence then lets me work without
rigidly committing to a design. I can continue to iterate the design as
needs and insights dictate.

And that seems like TDD is a design tool to me.

- George

* George Dinwiddie *
Software Development
Consultant and Coach

Augusto Rodriguez

Aug 29, 2016, 1:33:43 PM8/29/16
Hi all!

I just wanted to share a my thoughts (I think they are very much in line with what George said).

I don't think any practice on its own can produce a good design. But a good mix of practices can help discover a good design, and TDD, in my view, is a must have in that mix. GOOS does mention quite a few practices, such as SOLID, tell-don't-ask, hexagonal architecture, and probably many others I cannot recall now.

Also, I think it's important to develop a gut feeling about when starting with TDD brings no benefits and using pen and paper or a quick prototype is the way to go. A clear example of this is the Ron Jeffries approach to build a sudoku solver Vs Peter Novig's solution.

Probably the most important aspect is to be humble and accept that whatever we do we can still learn. And as a consequence, what are the tools or practices that allow us to learn in breadth and/or depth in the most efficient way.



--- You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
For more options, visit

Augusto Rodriguez
Reply all
Reply to author
0 new messages