开云体育

I would say that there are multiple levels of design, including architecture, systems design, security design, and so on. TDD isn’t intended to help with those. It helps you get to clean code, based on the idea of elimination of duplication, good cohesion, and so on. That’s a lower-level of design, but one of the most obvious when you’re having trouble understanding and maintaining code.?

-----------------

Author, HttpUnit <> and SimpleStub <>

Now blogging at <>

Have you listened to Edict Zero <>? If not, you don’t know what you’re missing!

On Jul 5, 2023, at 9:56 AM, Sleepyfox <sleepyfox@...> wrote:

The original proposition, partly, as stated is:

One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well"

I feel this falls into the trap of not being clear about what we mean
when we say TDD.
If one defines TDD as a process. Red, Green, Refactor.
First write a failing test.
Only write enough code to make the test pass.
Etc...

It seems to me that refactoring is the part of the TDD process where
we "improve the design of the running, tested code without changing
its functionality".
How can we improve the design, unless we already know what constitutes
good design, and what constitutes bad design? TDD itself doesn't tell
us, it is just a process. We must obtain the sensibilities of design
elsewhere.
I see one exception to this: design for testing. The act of trying to
write tests for code that is not designed for testing, using patterns
that we are familiar with that do not promote design for testing, will
make life painful. If we listen to our tests then we will try and
remove this pain, and by doing so blunder randomly into patterns that
promote design for testability.

In all other ways however I cannot see how good design sensibilities
are taught by the TDD process. They must be learned elsewhere.

I concede that there are probably things I might not be considering.
If someone has some proof of 'emergent properties of a simple system'
that show good design emerges from repeated application of the TDD
process without any external input (in terms of design), I would be
most interested.
TDD at least fulfils the requirement of fast feedback for a Chaotic system.

Fox
---

On Wed, 5 Jul 2023 at 10:12, Mauricio Aniche <mauricioaniche@...> wrote:

Hey, Charlie and Gregory,

Thanks for your message. Where did I get that from... This is a good question!

In the bubble of engineers I follow, I sometimes get the impression
that people believe that TDD is this thing that magically turns bad
code into good code. Or that the only way to achieve great design is
by doing TDD, if you don't, you'll produce crappy code. I disagree
with that, and I'm happy to see you also don't really see it this way.

I believe that, in order to make great design decisions, you need
input from many different points of view. Test code is one of them,
but certainly not the only nor the most effective one for all types of
design challenges. In many of the hardest design decisions I had to
take, my knowledge on OOD + lots of lessons learned and examples from
APIs I've read and developed in the past were the main drivers behind
my choices.

That being said, I see lots of advantages in the rhythm that TDD
brings, just like Gregory mentioned. TDD was the best teacher I could
ever have in terms of teaching me how to break something complex into
small bits, how to make sure I have tests to give me confidence, and
on how to focus on one thing at the time. Interestingly, one of my
favorite academic papers, by Fucci et al, conclude that " The claimed
benefits of TDD may not be due to its distinctive test-first dynamic,
but rather due to the fact that TDD-like processes encourage
fine-grained, steady steps that improve focus and flow." (in A
Dissection of the Test-Driven Development Process: Does It Really
Matter to Test-First or to Test-Last?)

Cheers,

--
Maurício Aniche
Author of Effective Software Testing: A Developer's Guide


On Tue, Jul 4, 2023 at 10:43?PM Gregory Salvan <apieum@...> wrote:

Mauricio, I believe like you "TDD doesn't magically guide you to good design", because it's not magic, it's focus.
Do you agree that TDD in itself can be seen as a frame that ensure you to think about your design often and check its resilience step by step ?

When you?e practicing TDD, for each small step, during refactoring phase, you've to focus on your design and how to improve it, this is how it leads to become better at design imo.
In my case I've observed, that the more I became experienced, the less I was breaking tests when modifying my code and the less changes were expensives. It sounds like the high flexibility you're talking about.