Does TDD really lead to good design?

[philip schwarz]

Does TDD really lead to good design? talk at Software Craftsmanship Barcelona 2015 - SCBCN15 published: http://codurance.com/videos/

[philip schwarz]

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?' https://www.youtube.com/watch?v=ApsW72JSVJM

...in 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 https://www.youtube.com/watch?v=ApsW72JSVJM

@philip_schwarz "TDD is not a design tool...there is zero prescription in the 'refactor' step of TDD" - https://www.youtube.com/watch?v=ApsW72JSVJM

@philip_schwarz "What are the 2 main styles of TDD?...The 2 schools are not opposites...u can mix & match" - https://www.youtube.com/watch?v=ApsW72JSVJM 

@philip_schwarz #GOOS start @ the periphery of the sys & work in.  I start in the center of the sys & work out https://groups.google.com/d/msg/clean-code-discussion/A6sJQjnwvnA/7ZmK0LGUtuIJ @unclebobmartin #TDD 

@philip_schwarz in the classicist approach,the unit under test may become bigger...use refactoring 2 extract https://www.youtube.com/watch?v=ApsW72JSVJM

@philip_schwarz @philip_schwarz related 2 unit under test growing:@ICooper in TDD,where did it all go wrong? https://vimeo.com/68375232

@philip_schwarz  classicist approach designs according 2 feedback from code+normally minimises upfront design https://www.youtube.com/watch?v=ApsW72JSVJM

@philip_schwarz I use the classicist approach when I don't have a proper domain e.g. when doing an algorithm https://www.youtube.com/watch?v=ApsW72JSVJM

That's how far I have got.

Philip

[Caio Fernando Bertoldi Paes de Andrade]

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?

Caio

—
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 growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jack Bolles]

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.

YMMV.
Jack

philip schwarz

29 November 2015 at 18:00

[Josue Barbosa dos Santos]

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,

you:

• 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

decisions

• 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

process

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. 

--

Abraços,
Josué
http://twitter.com/josuesantos