The best design does not exist in some timeless, isolated vacuum.? A design is only best with respect to the actual requirements for the software.? The actual requirements?are always a moving target (outside of formally mathematical software or shelf ware).? The "best design" must not just meet the current requirements, but must also be easily adaptable to unknown future requirements.? This is where a body of automated tests of different types are essential, even if you were able to create a great design without using TDD and/or ATDD (acceptance test driven development).
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.
> >
> >
> >
> >
>
>
>
>
>
