Does TDD really lead to good design?

Skip to first unread message

philip schwarz

Oct 27, 2015, 3:49:53 AM10/27/15
to Growing Object-Oriented Software
Does TDD really lead to good design? talk at Software Craftsmanship Barcelona 2015 - SCBCN15 published:

philip schwarz

Nov 29, 2015, 1:00:06 PM11/29/15
to Growing Object-Oriented Software
I had started watching this. 

FWIW - here are some excerpts I tweeted at the time.

31 Oct 2015 self: let me go through Sandro Mancuso's talk: 'Does TDD really lead to good design?' the past 5 years you will find many places with me saying TDD leads to good design, and I really strongly believed in that...why is it difficult for other people?

And why is it not difficult for other people...a group of people have no problem at all, but other peopl struggle a lot, I was always thinking: why?...another other thing, a lot of people can test drive the code, but not always the design is quite right after that...

00:03 if the red-green-refactor cycle is so easy to understand, why is it so hard to do? Where is the design here?

00:03:20 In TDD, where does the design happen? Refactor, what do we do in the refactor phase? What is the guideline? Make code better. Maintainable, Readable, all the -able ities. So what is the prescription here? What do we do? Just 'make the code better' doesn't help. That's why we fail. 'make the code better'. How? What are we looking for?

Has anyone heard about the Foru Rules of Simple Design (4RSD). In any order. Duplication. Pass the tests. Fewer elements. Reveal Intent. Where does this come from? Kent Beck, part of XP. Is this part of TDD? No it's not. I asked @ronJeffries, and he is one of the creators of TDD, of XP, alongside Kent Beck, and it's not. This (4RSD) is not TDD.

Where is the design part of TDD if that (4RSD) is not part of TDD? <Silence>. So how come it is a design tool?

31 Oct 2015 @philip_schwarz "Are the 4 rules of simple design part of TDD? No. I asked @RonJeffries" @sandromancuso in

@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

That's how far I have got.


Caio Fernando Bertoldi Paes de Andrade

Nov 29, 2015, 6:25:57 PM11/29/15
If the main point is about design, why are talking about refactoring? Why don't we ask people when do they redesign? When do they change their tests?


Sent from Mailbox


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

Jack Bolles

Nov 29, 2015, 8:10:42 PM11/29/15
I'd not heard of 4RSD. 

With TDD, for me, the D is about interface design. From there, a good API can be the basis for how and when to clean up and improve the code behind it. Being test-driven, the tests move 'Reveal Intent' to the front of queue.


29 November 2015 at 18:00

Josue Barbosa dos Santos

Dec 1, 2015, 7:06:40 AM12/1/15
From the book Test-Driven Development by Example (Kent Beck)

"But how do you get to clean code that works? Many forces drive you away from
clean code, and even code that works. Without taking too much counsel of our
fears, here’s what we do—drive development with automated tests, a style of development
called “Test-Driven Development” (TDD for short). In Test-Driven Development,
• Write new code only if you first have a failing automated test.
• Eliminate duplication.

Two simple rules, but they generate complex individual and group behavior. Some
of the technical implications are:

• You must design organically, with running code providing feedback between
• You must write your own tests, since you can’t wait twenty times a day for
someone else to write a test
• Your development environment must provide rapid response to small changes
• Your designs must consist of many highly cohesive, loosely coupled components,
just to make testing easy

The two rules imply an order to the tasks of programming:

1. Red—write a little test that doesn’t work, perhaps doesn’t even compile at first
2. Green—make the test work quickly, committing whatever sins necessary in the
3. Refactor—eliminate all the duplication created in just getting the test to work
Red/green/refactor. The TDDs mantra."

So for me it is not true that in TDD you have no clue of what to do in the refactor phase. From the seminal book you have to look at least for duplication. I think in the time the book was written Kent did not stress "express intent" or "minimize the number of classes and methods" and things like that because eliminating duplication would lead to code with this characteristics and he want just a single rule to simplify the thing. I am speculating here.

What I agree is that the ability to see duplication in code may vary. For example, when doing mentoring with peers here first they did not see many kinds of duplication. After a while they started to see the duplications but did not know how to eliminate them (for example apply a strategy or decorator).

I think that reading the good books out there (TDD by example, Refactoring, Design Patterns, Agile Practices Principles and Patterns, Clean Code, GOOS) is a good way to try to improve your skill. 

Reply all
Reply to author
0 new messages