Re: Which comes first: design skill or TDD?
On Wed, Jul 5, 2023 at 6:57?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"
That was JB's proposition. A good way to seed an active discussion is to throw in a red herring. :-)
If we wanted to be precise, I'd correct it to say "One can learn design skill _while_ practicing TDD." Alternatively, one might try to practice TDD and fail to learn design in the process.
I think we're approaching the "One True Scotsman" fallacy here. I'm tempted to say that anyone who doesn't practice improving design while doing TDD isn't "really" doing TDD. I'll resist that as being unhelpful. :-)
In fact, the folks who originated TDD pretty much universally situated it in the center of a set of practices - other practices - which supported it and were supported by it. XP is the classic example but not the only one. Being an old and continuing XP guy, I still use the XP terms. So... you can try to do Test Driven Development without
doing Simple Design, but you won't get nearly as far.
XP was a set of practices (originally 12) but IMO its real lesson is that you need _some_ set of practices, which work to support one another.
All of which is a long preamble to asking everyone this question: What __other__ practices do you find essential
when using TDD in your own work?
Charlie
|
Re: Which comes first: design skill or TDD?
On 7/5/23 9:56 AM, 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. The major point of software design is to make the code easy to understand, and therefore easy to work on. I learned enough about software design from writing essays in English classes and from Larry Constantine's work on coupling and cohesion that I could realize what changes were making it easier and harder to reason about the code. 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. Au contraire. I think you just have to pay attention as you work, and be willing to back up and try something different. 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
--- - George -- ---------------------------------------------------------------------- * George Dinwiddie * Software Development Consultant and Coach ----------------------------------------------------------------------
|
Re: Which comes first: design skill or TDD?
But TDD doesn't teach you about coupling and cohesion, it doesn't teach you about 'clean code' (whatever you determine that to mean), it doesn't even teach you about removal of duplication - that's Simple Design.
Fox
On Wed, 5 Jul 2023, 17:27 Russell Gold, < russ@...> wrote: 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!
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 meanwhen 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 wherewe "improve the design of the running, tested code without changingits functionality".How can we improve the design, unless we already know what constitutesgood design, and what constitutes bad design? TDD itself doesn't tellus, it is just a process. We must obtain the sensibilities of designelsewhere.I see one exception to this: design for testing. The act of trying towrite tests for code that is not designed for testing, using patternsthat we are familiar with that do not promote design for testing, willmake life painful. If we listen to our tests then we will try andremove this pain, and by doing so blunder randomly into patterns thatpromote design for testability.In all other ways however I cannot see how good design sensibilitiesare 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 TDDprocess without any external input (in terms of design), I would bemost 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.
|
Re: Which comes first: design skill or TDD?
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 <http://www.httpunit.org> and SimpleStub <http://simplestub.meterware.com> Now blogging at <http://russgold.net/sw/>
Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
toggle quoted message
Show quoted text
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 meanwhen 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 wherewe "improve the design of the running, tested code without changingits functionality".How can we improve the design, unless we already know what constitutesgood design, and what constitutes bad design? TDD itself doesn't tellus, it is just a process. We must obtain the sensibilities of designelsewhere.I see one exception to this: design for testing. The act of trying towrite tests for code that is not designed for testing, using patternsthat we are familiar with that do not promote design for testing, willmake life painful. If we listen to our tests then we will try andremove this pain, and by doing so blunder randomly into patterns thatpromote design for testability.In all other ways however I cannot see how good design sensibilitiesare 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 TDDprocess without any external input (in terms of design), I would bemost 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
https://www.mauricioaniche.com
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.
|
Re: Which comes first: design skill or TDD?
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.
> >
> >
> >
> >
>
>
>
>
>
|
Re: Which comes first: design skill or TDD?
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.
|
Re: Which comes first: design skill or TDD?
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
toggle quoted message
Show quoted text
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.
|
On 4 Jul 2023, at 14:22, J. B. Rainsberger <me@...> wrote: Which freedoms? Why do you care? What do those freedoms give you?
I have noticed these kinds of freedom:
- freedom from having to "get it right" the first time
- freedom from agonizing over design decisions
- freedom from the blank page These three. I remember about the time I was getting into TDD, sitting in a design session with some hot-shots from an MIT-founded company and the deer-in-the-headlights freeze because of the cost of making a commitment. Most of all, I enjoyed the freedom from thinking that I had to "be born with it" to design software systems well. This is the freedom I wish most to share with the most people. And that's why I teach TDD. I never associated that with TDD as a technique. I still see badly designed systems ¡°test-driven¡± but perhaps less badly than before. A colleague of mine had to deal with a very weak on-shore team in the early days. They took a long time to improve because it¡¯s hard to do good design when completely immune to development pain. S
|
Re: Which comes first: design skill or TDD?
"IMHO, TDD doesn't magically guide you to good design.". Very true.
However, it very concretely enables fast feedback loops. The fastest available anywhere. The closest rival is probably?web UI programming with live reload.
Which is heaven for those focused on experimenting and learning.
So, TDD, combined with the intent of learning good design very?much helps you towards good design.?
Hi, JB! Thanks for starting such an interesting thread.
I'm a strong believer in a slight variation of what you said. If you
want to get the best out of TDD, you need to deeply know about
software design.
IMHO, TDD doesn't magically guide you to good design. Sure, in
information systems, where many of the design decisions are related to
object creation and encapsulation, TDD is a great way to quickly
validate if you are going in a good direction. Maybe in such cases you
don't really need a deep background in OOD to listen to your tests
saying that your class is hard to be instantiated or that you aren't
encapsulating things properly, and so, TDD pays off handsomely even to
those that still haven't mastered OOD.
However, if you are building highly flexible applications / libraries
/ frameworks, I hardly think that TDD is enough. As an example of a
library I was diving into the code today: the extensibility model of
JUnit 5. It was clearly created by someone who profoundly understands
object-oriented design principles and how to build elegant and
flexible APIs. A non-expert in OOD, even with TDD, wouldn't be able to
do it no matter how perfect their TDD sessions were.
Cheers,
--
Maur¨ªcio Aniche
Author of Effective Software Testing: A Developer's Guide
On Tue, Jul 4, 2023 at 6:55?PM Russell Gold <russ@...> wrote:
>
> Refactoring to simplify code leads to cleaner designs. If nothing else, you should get a better feel for what makes a clean design. On the other hand, if by ¡°design¡± you¡¯re thinking mainly systems-level, I don¡¯t really see TDD as helping.
>
>
>
>
> On Jul 4, 2023, at 10:05 AM, Kevin Rutherford <kevin@...> wrote:
>
> JB,
> I'm quite surprised by your second claim, that "One can learn design
> skill by practising TDD".
> Can you support that?
>
> K
>
> On Tue, Jul 4, 2023 at 2:43?PM J. B. Rainsberger <me@...> wrote:
>
>
> I am surprised to encounter so many people who claim something like this:
>
> "You must understand how to design before you can practise TDD well."
>
> I say the following in response:
>
> - Practising TDD "poorly" still helps many programmers
> - One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well"
> - Your claim, framed that way, needlessly scares programmers away from TDD who need it
>
> Practising TDD well and improving design skill forms an amplifying feedback loop, don't you think?
> --
> J. B. (Joe) Rainsberger :: tdd.training :: ::
>
>
> Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
>
> --
> J. B. (Joe) Rainsberger :: :: ::
> Teaching evolutionary design and TDD since 2002
>
>
> -----------------
> Author, HttpUnit <> and SimpleStub <>
> Now blogging at <>
>
> Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
>
>
|
Re: Which comes first: design skill or TDD?
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.
?
|
Re: Which comes first: design skill or TDD?
For me, learning TDD the hard way (by doing it a lot, badly, with little guidance beyond the books and dev blogs available in the early oughts) led to a massive improvement in my software design skill. More than that, it changed the way I think about software design so that even when not doing TDD for (reasons), I write "testable" code, because?"testable" just means "simple".
Big caveat: I was about 10 years into my career when I first tried something-called-TDD, and it was maybe 5 more years before I felt comfortable enough to mentor others. It's possible that this improvement was due to other reasons, and just happened to coincide with TDD adoption. But I don't think so.
I've also observed a similar growth in folks I've mentored, of varying experience levels, in the 15 or so years since I first felt comfortable with TDD. Again though, It's really hard to definitively attribute this to TDD. Usually TDD is practiced by more experienced?programmers, so an environment of TDD-ers is probably generally good at mentorship. It also tends to correlate with other collaborative XP-descended working styles, which probably has a positive effect on such things.
Learning TDD by just doing it, even badly, really taught me about its traps -- overmocking, falling back to end-to-end testing in a "hard-to-test" system, focusing too much on trying to simulate human behavior, just plain writing too many tests, and a whole lot more. Recognizing those traps is really useful when guiding less experienced folks on their journeys.
If I think back on it, it occurs to me that when I was learning TDD, I followed red/green/refactor extremely closely (although at first, like most, I didn't focus on the refactor step enough). Now, I really don't hew to that cycle very often. I don't even know if I can claim to do TDD regularly at present, by common definition.
Dave
Hi, JB! Thanks for starting such an interesting thread.
I'm a strong believer in a slight variation of what you said. If you
want to get the best out of TDD, you need to deeply know about
software design.
IMHO, TDD doesn't magically guide you to good design. Sure, in
information systems, where many of the design decisions are related to
object creation and encapsulation, TDD is a great way to quickly
validate if you are going in a good direction. Maybe in such cases you
don't really need a deep background in OOD to listen to your tests
saying that your class is hard to be instantiated or that you aren't
encapsulating things properly, and so, TDD pays off handsomely even to
those that still haven't mastered OOD.
However, if you are building highly flexible applications / libraries
/ frameworks, I hardly think that TDD is enough. As an example of a
library I was diving into the code today: the extensibility model of
JUnit 5. It was clearly created by someone who profoundly understands
object-oriented design principles and how to build elegant and
flexible APIs. A non-expert in OOD, even with TDD, wouldn't be able to
do it no matter how perfect their TDD sessions were.
Cheers,
--
Maur¨ªcio Aniche
Author of Effective Software Testing: A Developer's Guide
On Tue, Jul 4, 2023 at 6:55?PM Russell Gold <russ@...> wrote:
>
> Refactoring to simplify code leads to cleaner designs. If nothing else, you should get a better feel for what makes a clean design. On the other hand, if by ¡°design¡± you¡¯re thinking mainly systems-level, I don¡¯t really see TDD as helping.
>
>
>
>
> On Jul 4, 2023, at 10:05 AM, Kevin Rutherford <kevin@...> wrote:
>
> JB,
> I'm quite surprised by your second claim, that "One can learn design
> skill by practising TDD".
> Can you support that?
>
> K
>
> On Tue, Jul 4, 2023 at 2:43?PM J. B. Rainsberger <me@...> wrote:
>
>
> I am surprised to encounter so many people who claim something like this:
>
> "You must understand how to design before you can practise TDD well."
>
> I say the following in response:
>
> - Practising TDD "poorly" still helps many programmers
> - One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well"
> - Your claim, framed that way, needlessly scares programmers away from TDD who need it
>
> Practising TDD well and improving design skill forms an amplifying feedback loop, don't you think?
> --
> J. B. (Joe) Rainsberger :: tdd.training :: ::
>
>
> Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
>
> --
> J. B. (Joe) Rainsberger :: :: ::
> Teaching evolutionary design and TDD since 2002
>
>
> -----------------
> Author, HttpUnit <> and SimpleStub <>
> Now blogging at <>
>
> Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
>
>
|
Re: Which comes first: design skill or TDD?
Hi Mauricio,
You make an interesting point, saying that the JUnit 5 extensibility model "was clearly created by someone who profoundly understands object-oriented design principles and how to build elegant and flexible APIs. A non-expert in OOD, even with TDD, wouldn't be able to do it no matter how perfect their TDD sessions were."
So, are you suggesting that TDD __ought__ to do that? Or possibly that some TDD practitioners / apostles have said it will do that? I'd be interested to know why that point comes up for you.
For myself, I have believed since my first experiences with TDD (ca. 2001) that I never believed TDD could allow me to do things I don't already know how to do. Possibly more important, the folks I learned from (Jeffries, Beck, Cunningham) never downplayed the need for deep understanding in developing truly elegant and flexible software. The point (at least as I learned it) is that TDD comes very close(*) to guaranteeing __working__ software.
Of course, back in the day, I worked in a context where other folks were already developing elegant designs... but the software didn't necessarily work. :-) I wonder if that still happens?
Charlie
* I think we all know that TDD, taken in isolation, doesn't guarantee that the software works the way the client wants it to work. Other practices are needed for that.
Hi, JB! Thanks for starting such an interesting thread.
I'm a strong believer in a slight variation of what you said. If you
want to get the best out of TDD, you need to deeply know about
software design.
IMHO, TDD doesn't magically guide you to good design. Sure, in
information systems, where many of the design decisions are related to
object creation and encapsulation, TDD is a great way to quickly
validate if you are going in a good direction. Maybe in such cases you
don't really need a deep background in OOD to listen to your tests
saying that your class is hard to be instantiated or that you aren't
encapsulating things properly, and so, TDD pays off handsomely even to
those that still haven't mastered OOD.
However, if you are building highly flexible applications / libraries
/ frameworks, I hardly think that TDD is enough. As an example of a
library I was diving into the code today: the extensibility model of
JUnit 5. It was clearly created by someone who profoundly understands
object-oriented design principles and how to build elegant and
flexible APIs. A non-expert in OOD, even with TDD, wouldn't be able to
do it no matter how perfect their TDD sessions were.
Cheers,
--
Maur¨ªcio Aniche
Author of Effective Software Testing: A Developer's Guide
On Tue, Jul 4, 2023 at 6:55?PM Russell Gold <russ@...> wrote:
>
> Refactoring to simplify code leads to cleaner designs. If nothing else, you should get a better feel for what makes a clean design. On the other hand, if by ¡°design¡± you¡¯re thinking mainly systems-level, I don¡¯t really see TDD as helping.
>
>
>
>
> On Jul 4, 2023, at 10:05 AM, Kevin Rutherford <kevin@...> wrote:
>
> JB,
> I'm quite surprised by your second claim, that "One can learn design
> skill by practising TDD".
> Can you support that?
>
> K
>
> On Tue, Jul 4, 2023 at 2:43?PM J. B. Rainsberger <me@...> wrote:
>
>
> I am surprised to encounter so many people who claim something like this:
>
> "You must understand how to design before you can practise TDD well."
>
> I say the following in response:
>
> - Practising TDD "poorly" still helps many programmers
> - One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well"
> - Your claim, framed that way, needlessly scares programmers away from TDD who need it
>
> Practising TDD well and improving design skill forms an amplifying feedback loop, don't you think?
> --
> J. B. (Joe) Rainsberger :: tdd.training :: ::
>
>
> Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
>
> --
> J. B. (Joe) Rainsberger :: :: ::
> Teaching evolutionary design and TDD since 2002
>
>
> -----------------
> Author, HttpUnit <> and SimpleStub <>
> Now blogging at <>
>
> Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
>
>
|
Re: Which comes first: design skill or TDD?
Hi, JB! Thanks for starting such an interesting thread.
I'm a strong believer in a slight variation of what you said. If you
want to get the best out of TDD, you need to deeply know about
software design.
IMHO, TDD doesn't magically guide you to good design. Sure, in
information systems, where many of the design decisions are related to
object creation and encapsulation, TDD is a great way to quickly
validate if you are going in a good direction. Maybe in such cases you
don't really need a deep background in OOD to listen to your tests
saying that your class is hard to be instantiated or that you aren't
encapsulating things properly, and so, TDD pays off handsomely even to
those that still haven't mastered OOD.
However, if you are building highly flexible applications / libraries
/ frameworks, I hardly think that TDD is enough. As an example of a
library I was diving into the code today: the extensibility model of
JUnit 5. It was clearly created by someone who profoundly understands
object-oriented design principles and how to build elegant and
flexible APIs. A non-expert in OOD, even with TDD, wouldn't be able to
do it no matter how perfect their TDD sessions were.
Cheers,
--
Maur¨ªcio Aniche
Author of Effective Software Testing: A Developer's Guide
toggle quoted message
Show quoted text
On Tue, Jul 4, 2023 at 6:55?PM Russell Gold <russ@...> wrote:
Refactoring to simplify code leads to cleaner designs. If nothing else, you should get a better feel for what makes a clean design. On the other hand, if by ¡°design¡± you¡¯re thinking mainly systems-level, I don¡¯t really see TDD as helping.
On Jul 4, 2023, at 10:05 AM, Kevin Rutherford <kevin@...> wrote:
JB,
I'm quite surprised by your second claim, that "One can learn design
skill by practising TDD".
Can you support that?
K
On Tue, Jul 4, 2023 at 2:43?PM J. B. Rainsberger <me@...> wrote:
I am surprised to encounter so many people who claim something like this:
"You must understand how to design before you can practise TDD well."
I say the following in response:
- Practising TDD "poorly" still helps many programmers
- One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well"
- Your claim, framed that way, needlessly scares programmers away from TDD who need it
Practising TDD well and improving design skill forms an amplifying feedback loop, don't you think?
--
J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca ::
blog.thecodewhisperer.com
Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
-----------------
Author, HttpUnit <> and SimpleStub <>
Now blogging at <>
Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
|
Re: Which comes first: design skill or TDD?
Refactoring to simplify code leads to cleaner designs. If nothing else, you should get a better feel for what makes a clean design. On the other hand, if by ¡°design¡± you¡¯re thinking mainly systems-level, I don¡¯t really see TDD as helping.?
On Jul 4, 2023, at 10:05 AM, Kevin Rutherford <kevin@...> wrote:
JB,I'm quite surprised by your second claim, that "One can learn designskill by practising TDD".Can you support that?KOn Tue, Jul 4, 2023 at 2:43?PM J. B. Rainsberger <me@...> wrote:
I am surprised to encounter so many people who claim something like this:
"You must understand how to design before you can practise TDD well."
I say the following in response:
- Practising TDD "poorly" still helps many programmers
- One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well"
- Your claim, framed that way, needlessly scares programmers away from TDD who need it
Practising TDD well and improving design skill forms an amplifying feedback loop, don't you think?
--
J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca ::
blog.thecodewhisperer.com
Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
--
J. B. (Joe) Rainsberger :: https://tdd.training :: https://blog.thecodewhisperer.com :: https://blog.jbrains.ca
Teaching evolutionary design and TDD since 2002
----------------- Author, HttpUnit <http://www.httpunit.org> and SimpleStub <http://simplestub.meterware.com> Now blogging at <http://russgold.net/sw/>
Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
|
Re: Classifying tests: problem? solution? something else?
I agree that the naming can be confusing because often the same name means different things to different people. I don't get too hung up on the naming of types of tests (though I love Gpaw's "microtests" because it gets out of the "unit test" mire). Instead, I tray to talk about the meaning the other person has behind the name.
When I started doing TDD, I sorted my tests into three categories:
- "unit tests" which tested in memory code without any other dependencies
- "database tests" which tested code dependent on the database. This led me to using the Adapter Pattern so I could isolate my unit tests from the database and test only the adapter against a real database.
- "deployed tests" which required the system to be deployed in order to run. These tended to be "story tests," though I found that by delegating from the requirements of the app server (J2EE in those days) to Plain Old Java Objects with the same API, I could implement most of the story tests the same way as unit tests, so "story tests" became another category.
Eventually I had need to call other systems beyond the database, so those became another classification of tests, but done in the same fashion as the database tests.
- George
toggle quoted message
Show quoted text
On 7/4/23 9:38 AM, J. B. Rainsberger wrote: > I think the test name separation by unit test/integration test/micro
test/behaviour test doesn't work, but I'm not sure what's the "sensible" way to separate them yetlike fast/slow/io/non-io? business/technical?structure vs behaviour?
I'm curious about this, because I hear it from time to time.
I have some questions, and we don't have to limit those to Tony, although I'm also interested in his replies:
1. What kind of "doesn't work"? It works for me, so maybe we have different ideas about how it could work or should work.
2. I classify tests in order to better understand all the different kinds of intent and purpose we have when we write them. This helps me decide how to choose which tests to write next. What challenges do you have with all these test classifications?
3. Some people report that there are too many test classifications to understand well. They become confused. I empathize. Why don't you simply ignore those classifications until you need them?
Finally, as for the difference between business and technical tests, when I talk about TDD I tend to focus on technical tests, because that's my context for TDD: to focus on the code. I handle Customer Tests (or business tests) quite differently, and I only sometimes practise what we've called Story-TDD or Acceptance-TDD. I practise it most often when I play the role of Customer for myself, such as on my volunteer projects. I try _very hard_ to clarify this for the people I teach, but I always run the risk that the message doesn't make it through.
--
J. B. (Joe) Rainsberger :: tdd.training <>?:: jbrains.ca <> ::
blog.thecodewhisperer.com <>
Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
--
J. B. (Joe) Rainsberger :: <> :: <> :: <>
Teaching evolutionary design and TDD since 2002
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
To me the best is freedom from the
fear of making changes to the codebase late in time.
?
From another perspective I also like the
rails that TDD provides to my development: I have a repeatable way to make small increments at a constant pace. TDD gives me a safe method to walk my way through requirements.
?
--
Gian Carlo (gk)
?
?
I'd like to build on this in addition to echoing it.
Everyone, feel invited to join in. I'm asking everyone and not only George.
Which freedoms? Why do you care? What do those freedoms give you?
I have noticed these kinds of freedom:
- freedom from chasing after silly mistakes
- freedom from having to "get it right" the first time
- freedom from agonizing over design decisions
- freedom from the blank page
Most of all, I enjoyed the freedom from thinking that I had to "be born with it" to design software systems well. This is the freedom I wish most to share with the most people. And that's why I teach TDD.
--
J. B. (Joe) Rainsberger ::
?::
::
Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on
a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
?
toggle quoted message
Show quoted text
On Mon, Jun 26, 2023 at 5:04?PM George Dinwiddie <lists@...> wrote:
"That's what TDD is, you know.
It's not just test cases and assertions
and a suite and a test runner.
That's what TDD needs.
But what TDD is... is freedom."
On 6/26/23 12:59 PM, George Dinwiddie wrote:
> Joe,
>
> There are a lot of aspects I could mention, but it basically comes down
> to the fact that TDD made my software development joyful. The worrisome
> aspects were out of my head and into test code.
>
>? ?- George
>
> On 6/26/23 9:21 AM, J. B. Rainsberger wrote:
>> Hi, folks. Why do you still care about TDD?
>>
>> Please skip the platitudes and write from the heart. Why does it still
>> matter to you? Why do you still practise it? How does it still help?
>> Why do you still teach it?
>>
>> Or not?
>> --
>> J. B. (Joe) Rainsberger :: tdd.training <>?::
>> <>
::
>> <>
>>
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach? ? ? ? ?
? ----------------------------------------------------------------------
--
J. B. (Joe) Rainsberger :: ::
::
Teaching evolutionary design and TDD since 2002
|
Re: Which comes first: design skill or TDD?
Kevin,
My experience supports that. I learned to be a much better OO designer by practicing TDD. It gave me the freedom to correct the design flaws I'd made, and see how much better coding worked after doing so.
- George
toggle quoted message
Show quoted text
On 7/4/23 10:05 AM, Kevin Rutherford wrote: JB,
I'm quite surprised by your second claim, that "One can learn design
skill by practising TDD".
Can you support that?
K
On Tue, Jul 4, 2023 at 2:43?PM J. B. Rainsberger <me@...> wrote:
I am surprised to encounter so many people who claim something like this:
"You must understand how to design before you can practise TDD well."
I say the following in response:
- Practising TDD "poorly" still helps many programmers
- One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well"
- Your claim, framed that way, needlessly scares programmers away from TDD who need it
Practising TDD well and improving design skill forms an amplifying feedback loop, don't you think?
--
J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca ::
blog.thecodewhisperer.com
Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
- freedom from having to hold the details of the assumptions of dependent code in you head, the tests will let you know if you violate them (to the extent you express those assumptions in tests)
- freedom from having to trace all the consequences of a bug fix. I can fix the obvious problem, and my tests will tell me what else I need to fix.
- freedom to push the code into a shape that's easier to understand, without worrying that I'll break something.
- freedom from worrying that I've unknowingly broken something that was working before.
toggle quoted message
Show quoted text
On 7/4/23 9:22 AM, J. B. Rainsberger wrote: I'd like to build on this in addition to echoing it.
Everyone, feel invited to join in. I'm asking everyone and not only George.
Which freedoms? Why do you care? What do those freedoms give you?
I have noticed these kinds of freedom:
- freedom from chasing after silly mistakes
- freedom from having to "get it right" the first time
- freedom from agonizing over design decisions
- freedom from the blank page
Most of all, I enjoyed the freedom from thinking that I had to "be born with it" to design software systems well. This is the freedom I wish most to share with the most people. And that's why I teach TDD.
--
J. B. (Joe) Rainsberger :: tdd.training <>?:: jbrains.ca <> ::
blog.thecodewhisperer.com <>
Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
On Mon, Jun 26, 2023 at 5:04?PM George Dinwiddie <lists@... <mailto:lists@...>> wrote:
"That's what TDD is, you know.
It's not just test cases and assertions
and a suite and a test runner.
That's what TDD needs.
But what TDD is... is freedom."
On 6/26/23 12:59 PM, George Dinwiddie wrote:
> Joe,
>
> There are a lot of aspects I could mention, but it basically
comes down
> to the fact that TDD made my software development joyful. The
worrisome
> aspects were out of my head and into test code.
>
>? ?- George
>
> On 6/26/23 9:21 AM, J. B. Rainsberger wrote:
>> Hi, folks. Why do you still care about TDD?
>>
>> Please skip the platitudes and write from the heart. Why does it
still
>> matter to you? Why do you still practise it? How does it still
help?
>> Why do you still teach it?
>>
>> Or not?
>> --
>> J. B. (Joe) Rainsberger :: tdd.training <
<>>?::
>> jbrains.ca <> <
<>> ::
>> blog.thecodewhisperer.com <>
< <>>
>>
>
--
----------------------------------------------------------------------
? ?* George Dinwiddie *
<>
? ?Software Development
<>
? ?Consultant and Coach
<>
----------------------------------------------------------------------
--
J. B. (Joe) Rainsberger :: <> :: <> :: <>
Teaching evolutionary design and TDD since 2002
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
Freedom from frequent,? long debugging sessions
On Tue, Jul 4, 2023, 10:12 Tim Ottinger < tottinge@...> wrote: Freedom to refactor, knowing you can check your work after each variable rename to know if you've made a mistake.?
On Tue, Jul 4, 2023, 08:23 J. B. Rainsberger < me@...> wrote: I'd like to build on this in addition to echoing it.
Everyone, feel invited to join in. I'm asking everyone and not only George.
Which freedoms? Why do you care? What do those freedoms give you?
I have noticed these kinds of freedom:
- freedom from chasing after silly mistakes - freedom from having to "get it right" the first time - freedom from agonizing over design decisions - freedom from the blank page
Most of all, I enjoyed the freedom from thinking that I had to "be born with it" to design software systems well. This is the freedom I wish most to share with the most people. And that's why I teach TDD. -- J. B. (Joe) Rainsberger :: ?:: ::
Replies
from this account routinely take a few days, which allows me to reply
thoughtfully. I reply more quickly to messages that clearly require
answers urgently. If you need something from me and are on a deadline,
then let me know how soon you need a reply so that I can better help you
to get what you need. Thank you for your consideration. On Mon, Jun 26, 2023 at 5:04?PM George Dinwiddie < lists@...> wrote: "That's what TDD is, you know.
It's not just test cases and assertions
and a suite and a test runner.
That's what TDD needs.
But what TDD is... is freedom."
On 6/26/23 12:59 PM, George Dinwiddie wrote:
> Joe,
>
> There are a lot of aspects I could mention, but it basically comes down
> to the fact that TDD made my software development joyful. The worrisome
> aspects were out of my head and into test code.
>
>? ?- George
>
> On 6/26/23 9:21 AM, J. B. Rainsberger wrote:
>> Hi, folks. Why do you still care about TDD?
>>
>> Please skip the platitudes and write from the heart. Why does it still
>> matter to you? Why do you still practise it? How does it still help?
>> Why do you still teach it?
>>
>> Or not?
>> --
>> J. B. (Joe) Rainsberger :: tdd.training <>?::
>> <> ::
>> <>
>>
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach? ? ? ? ?
? ----------------------------------------------------------------------
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
|
Freedom to refactor, knowing you can check your work after each variable rename to know if you've made a mistake.?
On Tue, Jul 4, 2023, 08:23 J. B. Rainsberger < me@...> wrote: I'd like to build on this in addition to echoing it.
Everyone, feel invited to join in. I'm asking everyone and not only George.
Which freedoms? Why do you care? What do those freedoms give you?
I have noticed these kinds of freedom:
- freedom from chasing after silly mistakes - freedom from having to "get it right" the first time - freedom from agonizing over design decisions - freedom from the blank page
Most of all, I enjoyed the freedom from thinking that I had to "be born with it" to design software systems well. This is the freedom I wish most to share with the most people. And that's why I teach TDD. -- J. B. (Joe) Rainsberger :: ?:: ::
Replies
from this account routinely take a few days, which allows me to reply
thoughtfully. I reply more quickly to messages that clearly require
answers urgently. If you need something from me and are on a deadline,
then let me know how soon you need a reply so that I can better help you
to get what you need. Thank you for your consideration. On Mon, Jun 26, 2023 at 5:04?PM George Dinwiddie < lists@...> wrote: "That's what TDD is, you know.
It's not just test cases and assertions
and a suite and a test runner.
That's what TDD needs.
But what TDD is... is freedom."
On 6/26/23 12:59 PM, George Dinwiddie wrote:
> Joe,
>
> There are a lot of aspects I could mention, but it basically comes down
> to the fact that TDD made my software development joyful. The worrisome
> aspects were out of my head and into test code.
>
>? ?- George
>
> On 6/26/23 9:21 AM, J. B. Rainsberger wrote:
>> Hi, folks. Why do you still care about TDD?
>>
>> Please skip the platitudes and write from the heart. Why does it still
>> matter to you? Why do you still practise it? How does it still help?
>> Why do you still teach it?
>>
>> Or not?
>> --
>> J. B. (Joe) Rainsberger :: tdd.training <>?::
>> <> ::
>> <>
>>
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach? ? ? ? ?
? ----------------------------------------------------------------------
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
|
Sleepyfox
Gu?laugur Egilsson
Gregory Salvan