Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
TDD can be useful even when it doesn't achieve what you want
178 views
Skip to first unread message
Juha Nieminen
Feb 15, 2016, 4:49:39 PM2/15/16
to
As a contrast to the recent "TDD is harmful" thread, I would like to
recount something I thought of recently in regards to a situation
where TDD doesn't actually achieve what you want, but can still make
your code better regardless.
Suppose you have a problem like this: You have made a small class
that opens a file (for example an image file) and does something with
it. One of the things you want to test is that the class actually ends
up closing the file (at the latest when it's destroyed). How would you
test this?
Since you are TDD-conscious, mock objects come to you naturally.
Therefore the solution seems to be clear: You have to make a mock
object that behaves like a file handle. To do this, you have to change
the class so that it takes a more abstract file handle than eg. a FILE*
or a std::istream. Once this is done, you can easily create a test to
make sure that your file-handling class ends up eventually closing the
file (by creating a mock file handler object that makes this check and
giving it to the class.)
However, there's a problem here: How do we now test that this abstract
file handle (which itself uses eg a FILE* or a std::istream) ends up
closing the file (at the latest when it's destroyed)? We realize that
all we have done is just transfer the problem to another class, and we
have ended up in an ouroboros situation. How could we test this? Create
yet *another* abstract file handle which we can mock? That wouldn't make
much sense since we just did exactly that, and it didn't really help.
We would just be in a vicious cycle.
So TDD didn't actually help us solve the actual problem we were trying
to solve.
*However* TDD *did* help us, in a natural way, to make our original class
better. That's because now it's more abstract and flexible. We have
changed it from being hard-coded to use a standard file handle into
being abstract, which makes it more flexible. (After all, it now supports
other types of input for the data it needs to read. We can now make
all kinds of abstract "file handle" objects that feed it data from
whatever other resource that might not be a file.)
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
recount something I thought of recently in regards to a situation
where TDD doesn't actually achieve what you want, but can still make
your code better regardless.
Suppose you have a problem like this: You have made a small class
that opens a file (for example an image file) and does something with
it. One of the things you want to test is that the class actually ends
up closing the file (at the latest when it's destroyed). How would you
test this?
Since you are TDD-conscious, mock objects come to you naturally.
Therefore the solution seems to be clear: You have to make a mock
object that behaves like a file handle. To do this, you have to change
the class so that it takes a more abstract file handle than eg. a FILE*
or a std::istream. Once this is done, you can easily create a test to
make sure that your file-handling class ends up eventually closing the
file (by creating a mock file handler object that makes this check and
giving it to the class.)
However, there's a problem here: How do we now test that this abstract
file handle (which itself uses eg a FILE* or a std::istream) ends up
closing the file (at the latest when it's destroyed)? We realize that
all we have done is just transfer the problem to another class, and we
have ended up in an ouroboros situation. How could we test this? Create
yet *another* abstract file handle which we can mock? That wouldn't make
much sense since we just did exactly that, and it didn't really help.
We would just be in a vicious cycle.
So TDD didn't actually help us solve the actual problem we were trying
to solve.
*However* TDD *did* help us, in a natural way, to make our original class
better. That's because now it's more abstract and flexible. We have
changed it from being hard-coded to use a standard file handle into
being abstract, which makes it more flexible. (After all, it now supports
other types of input for the data it needs to read. We can now make
all kinds of abstract "file handle" objects that feed it data from
whatever other resource that might not be a file.)
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Mr Flibble
Feb 15, 2016, 4:57:09 PM2/15/16
to
appropriate abstractions without using TDD.
/Flibble
Wouter van Ooijen
Feb 15, 2016, 5:59:56 PM2/15/16
to
Op 15-Feb-16 om 10:49 PM schreef Juha Nieminen:
TDD might have helped *you* in *this case*, but so would any
design/development method that pays attention to testability. (And on
top of that, any design method that pays attention to abstraction and
re-use).
Wouter van Ooijen
design/development method that pays attention to testability. (And on
top of that, any design method that pays attention to abstraction and
re-use).
Wouter van Ooijen
Juha Nieminen
Feb 16, 2016, 4:10:01 AM2/16/16
to
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
> I am, and I am sure many others are, quite capable of creating
> appropriate abstractions without using TDD.
You are missing the point.
> I am, and I am sure many others are, quite capable of creating
> appropriate abstractions without using TDD.
Juha Nieminen
Feb 16, 2016, 4:12:56 AM2/16/16
to
Wouter van Ooijen <wou...@voti.nl> wrote:
> TDD might have helped *you* in *this case*, but so would any
> design/development method that pays attention to testability. (And on
> top of that, any design method that pays attention to abstraction and
> re-use).
How many of those methods actually induce you to both increase the
> TDD might have helped *you* in *this case*, but so would any
> design/development method that pays attention to testability. (And on
> top of that, any design method that pays attention to abstraction and
> re-use).
abstraction of your designs and create tests for your modules at
the same time?
Why this hate of TDD? I don't understand.
Öö Tiib
Feb 16, 2016, 6:08:40 AM2/16/16
to
On Tuesday, 16 February 2016 11:12:56 UTC+2, Juha Nieminen wrote:
> Wouter van Ooijen <wou...@voti.nl> wrote:
> > TDD might have helped *you* in *this case*, but so would any
> > design/development method that pays attention to testability. (And on
> > top of that, any design method that pays attention to abstraction and
> > re-use).
>
> How many of those methods actually induce you to both increase the
> abstraction of your designs and create tests for your modules at
> the same time?
>
> Why this hate of TDD? I don't understand.
I think that it is like always when some sort of process, method,
> Wouter van Ooijen <wou...@voti.nl> wrote:
> > TDD might have helped *you* in *this case*, but so would any
> > design/development method that pays attention to testability. (And on
> > top of that, any design method that pays attention to abstraction and
> > re-use).
>
> How many of those methods actually induce you to both increase the
> abstraction of your designs and create tests for your modules at
> the same time?
>
> Why this hate of TDD? I don't understand.
technique or tool is too inconvenient, badly supported, misapplied
and/or overused somehow.
To be more concrete:
* They do not do not test units in isolation (typically because testing
framework is weak).
* They handwrite (or manually correct) lot of mocks, fakes and dummies
(typically because testing framework is weak).
* The tests look like cryptic garbage (typically because testing framework
used has verbose and complex setup interface).
* One test checks too several things so it is hard to say what it tests
without using word "and" several times (typically because of one or
more from previous issues).
* TDD (as silver bullet tool and design process) is valued over
individuals and interactions within organization.
* Unit test code coverage (as the holy metric of quality) is valued over
working software within organization.
* and/or other such issues.
These are called as strawmen but are likely real issues because It can take
time, debates, work and effort to get corrected. Only few (one?) of such
issues is plenty for someone to become toxic.
Wouter van Ooijen
Feb 16, 2016, 11:16:59 AM2/16/16
to
Op 16-Feb-16 om 10:12 AM schreef Juha Nieminen:
like is the set of 3 rules. (And the implied 4'th rule, that someone who
doesn't always use TDD is not a professional.) If that is different from
TDD, please interpret my objections (or even hate) as directed to those
3 rules. But if those 3 rules are essential to TDD, yes, *then* I hate TDD.
I have no objection to TDD as a suggestion of how to organise your work,
alsongside other suggestions like (rapid) prototyping, waterfall (yes!),
agile, scrum, peer programming, egoless programming, and a long list of
others. As always, the job of an engineer is to choose the right tool
for the job at hand.
Wwouter van Ooijen
> Wouter van Ooijen <wou...@voti.nl> wrote:
>> TDD might have helped *you* in *this case*, but so would any
>> design/development method that pays attention to testability. (And on
>> top of that, any design method that pays attention to abstraction and
>> re-use).
>
> How many of those methods actually induce you to both increase the
> abstraction of your designs and create tests for your modules at
> the same time?
>
> Why this hate of TDD? I don't understand.
TDD is just a term/word/phrase, nothing to hate or love. What I don't
>> TDD might have helped *you* in *this case*, but so would any
>> design/development method that pays attention to testability. (And on
>> top of that, any design method that pays attention to abstraction and
>> re-use).
>
> How many of those methods actually induce you to both increase the
> abstraction of your designs and create tests for your modules at
> the same time?
>
> Why this hate of TDD? I don't understand.
like is the set of 3 rules. (And the implied 4'th rule, that someone who
doesn't always use TDD is not a professional.) If that is different from
TDD, please interpret my objections (or even hate) as directed to those
3 rules. But if those 3 rules are essential to TDD, yes, *then* I hate TDD.
I have no objection to TDD as a suggestion of how to organise your work,
alsongside other suggestions like (rapid) prototyping, waterfall (yes!),
agile, scrum, peer programming, egoless programming, and a long list of
others. As always, the job of an engineer is to choose the right tool
for the job at hand.
Wwouter van Ooijen
Juha Nieminen
Feb 17, 2016, 6:27:21 AM2/17/16
to
Wouter van Ooijen <wou...@voti.nl> wrote:
> As always, the job of an engineer is to choose the right tool
> for the job at hand.
I don't think anybody (who knows anything) is claiming that TDD is
> As always, the job of an engineer is to choose the right tool
> for the job at hand.
the silver bullet, the perfect tool for every possible situation.
However, when properly used, properly applied, and when rigorously
followed, it increases the quality and design of programming projects.
It might not test every single potential bug that a program may have
(not even nearly), but it catches early on easy mistakes (and often
even more obscure ones). The time you "waste" on the TDD part can well
be saved in avoiding the bug hunting later on. Also, the design decisions
you do in order to make TDD work can pay off all in themselves as well.
That's not to say that the program cannot be designed poorly even when
using TDD properly. But there's a reason why so many people advocate it.
Mr Flibble
Feb 17, 2016, 11:55:21 AM2/17/16
to
On 17/02/2016 11:26, Juha Nieminen wrote:
> Wouter van Ooijen <wou...@voti.nl> wrote:
>> As always, the job of an engineer is to choose the right tool
>> for the job at hand.
>
> I don't think anybody (who knows anything) is claiming that TDD is
> the silver bullet, the perfect tool for every possible situation.
>
> However, when properly used, properly applied, and when rigorously
> followed, it increases the quality and design of programming projects.
Quite the contrary: TDD is anathema to good design.
> Wouter van Ooijen <wou...@voti.nl> wrote:
>> As always, the job of an engineer is to choose the right tool
>> for the job at hand.
>
> I don't think anybody (who knows anything) is claiming that TDD is
> the silver bullet, the perfect tool for every possible situation.
>
> However, when properly used, properly applied, and when rigorously
> followed, it increases the quality and design of programming projects.
/Flibble
Wouter van Ooijen
Feb 17, 2016, 12:57:26 PM2/17/16
to
Op 17-Feb-16 om 12:26 PM schreef Juha Nieminen:
PS Uncle Bob *does* claim that TTD is *the* tool to apply to every
programming problem.
> It might not test every single potential bug that a program may have
> (not even nearly), but it catches early on easy mistakes (and often
> even more obscure ones). The time you "waste" on the TDD part can well
> be saved in avoiding the bug hunting later on. Also, the design decisions
> you do in order to make TDD work can pay off all in themselves as well.
>
> That's not to say that the program cannot be designed poorly even when
> using TDD properly. But there's a reason why so many people advocate it.
Against those assertions I assert that there is a reason so many people
are against it.
Wouter
> Wouter van Ooijen <wou...@voti.nl> wrote:
>> As always, the job of an engineer is to choose the right tool
>> for the job at hand.
>
> I don't think anybody (who knows anything) is claiming that TDD is
> the silver bullet, the perfect tool for every possible situation.
>
> However, when properly used, properly applied, and when rigorously
> followed, it increases the quality and design of programming projects.
When I read these two scentences they seem to contradict each other.
>> As always, the job of an engineer is to choose the right tool
>> for the job at hand.
>
> I don't think anybody (who knows anything) is claiming that TDD is
> the silver bullet, the perfect tool for every possible situation.
>
> However, when properly used, properly applied, and when rigorously
> followed, it increases the quality and design of programming projects.
PS Uncle Bob *does* claim that TTD is *the* tool to apply to every
programming problem.
> It might not test every single potential bug that a program may have
> (not even nearly), but it catches early on easy mistakes (and often
> even more obscure ones). The time you "waste" on the TDD part can well
> be saved in avoiding the bug hunting later on. Also, the design decisions
> you do in order to make TDD work can pay off all in themselves as well.
>
> That's not to say that the program cannot be designed poorly even when
> using TDD properly. But there's a reason why so many people advocate it.
are against it.
Wouter
Ian Collins
Feb 17, 2016, 2:00:40 PM2/17/16
to
--
Ian Collins
Ian Collins
Feb 17, 2016, 2:02:21 PM2/17/16
to
--
Ian Collins
Wouter van Ooijen
Feb 17, 2016, 2:11:57 PM2/17/16
to
Op 17-Feb-16 om 8:02 PM schreef Ian Collins:
That's your assertion. I assert that they have good reasons.
(Of course when you define 'doing it well' as 'when it works' *any*
methodology works well....)
Wouter
(Of course when you define 'doing it well' as 'when it works' *any*
methodology works well....)
Wouter
Ian Collins
Feb 17, 2016, 2:23:59 PM2/17/16
to
TDD into a team there have always been some who initially opposed the
change and even some who at best grudgingly accepted it once the process
has bedded in. I think this comes down to personality type. Some feel
uneasy uneasy without detailed planning, others find planning stressful.
The same apples to development methodologies.
--
Ian Collins
Wouter van Ooijen
Feb 17, 2016, 2:32:34 PM2/17/16
to
Op 17-Feb-16 om 8:23 PM schreef Ian Collins:
You seem to be more reasonable than the 3-rule evangelists (
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd ). What is
in your opinion a good description of TDD?
Wouter
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd ). What is
in your opinion a good description of TDD?
Wouter
Ian Collins
Feb 17, 2016, 2:55:05 PM2/17/16
to
lost the evangelical zeal :)
I do follow the three rules, along with my fourth rule:
4) You are not allowed to fix any bug without adding a failing unit test.
TDD suites my way of thinking. I like to know, as that article says
that a minute ago all my code worked! I like just to be able to revert
a commit rather than mess with a debugger. I like to know that when I
change code I haven't broken it.
--
Ian Collins
Richard
Feb 17, 2016, 4:09:14 PM2/17/16
to
[Please do not mail me a copy of your followup]
Wouter van Ooijen <wou...@voti.nl> spake the secret code
<56c4b474$0$4233$e4fe...@newszilla.xs4all.nl> thusly:
>PS Uncle Bob *does* claim that TTD is *the* tool to apply to every
>programming problem.
What I've seen him claim is that he hasn't found anything better than
TDD. If you can show him something better than TDD, then he'll be
talking about that.
If you have something you think is better than TDD, bring it Uncle Bob
and get him to champion it. If you can convince Uncle Bob, I'm very
interested in hearing about it.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Wouter van Ooijen <wou...@voti.nl> spake the secret code
<56c4b474$0$4233$e4fe...@newszilla.xs4all.nl> thusly:
>PS Uncle Bob *does* claim that TTD is *the* tool to apply to every
>programming problem.
TDD. If you can show him something better than TDD, then he'll be
talking about that.
If you have something you think is better than TDD, bring it Uncle Bob
and get him to champion it. If you can convince Uncle Bob, I'm very
interested in hearing about it.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Cholo Lennon
Feb 17, 2016, 4:10:12 PM2/17/16
to
my experience) the TDD evangelists (teachers, bosses) are inflexible
with the methodology. I prefer guidelines or tips that you can
pick/discard if they are useful or not for you.
TDD is for me another tool to develop my software, sometimes it can
works well, sometimes it doesn't.
Regards
--
Cholo Lennon
Bs.As.
ARG
Ian Collins
Feb 17, 2016, 4:29:11 PM2/17/16
to
there is such a thing) XP process, they all adopted the process to fit
their people and external processes. In my opinion that is how agile
should be, every work environment is different, so there isn't a one
size fits all process. The same applies to managing a project with
Scrum, no two teams end up with the exact same process. The Dogma goes
against the philosophy of agile software development.
If I were starting with a new team today, I would would *start out* by
following a "strict" process and then adapt. That is the agile way:
tweak the process to fit the people, don't force the process on the people.
> TDD is for me another tool to develop my software, sometimes it can
> works well, sometimes it doesn't.
TDD, I tend to have a good look at when I and doing and find out why.
--
Ian Collins
Richard
Feb 17, 2016, 4:29:11 PM2/17/16
to
[Please do not mail me a copy of your followup]
Wouter van Ooijen <wou...@voti.nl> spake the secret code
<56c4c5ef$0$4200$e4fe...@newszilla.xs4all.nl> thusly:
Wouter van Ooijen <wou...@voti.nl> spake the secret code
>(Of course when you define 'doing [TDD] well' as 'when it works' *any*
>methodology works well....)
As someone that has introduced TDD to every team I've worked on for
the past 10 years, I can pretty quickly tell the difference between
someone doing it right and someone doing it wrong.
What is "doing it wrong"? Dr. Evil gives a nice example:
<http://cdn.meme.am/instances/54444468.jpg>
In general, the people I see struggling the most with TDD are the same
ones that struggle to make small methods and small classes. They
routinely violate SRP and the other SOLID OO design principles.
<https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)>
When practicing TDD, if your tests start getting complicated, that is
a signal being given to you by your code. The tests are telling you
that your implementation/design is too complex. Someone who is used
to writing long complicated methods and isn't used to following SRP
chafes against TDD because it is actively making it hard for them to
do what they are used to doing.
Psychologically this puts you in a bind. You want to embrace SRP and
other SOLID design principles, because everyone knows they are
intrinsicly "good". Historically your code doesn't embody those
principles, but this hasn't been explicitly brought to your attention
or you've rationalized away your violations of those design principles
through utility or necessity. TDD is putting your feet to the fire
and forcing you to adhere to those principles in practice and not just
in theory. Doing this means changing the way you've been writing
code. It's uncomfortable. It's painful to write code in the familiar
way with TDD because your tests get really complicated and painful to
write.
I've seen people work their way out of this psychological bind in two
ways:
1. Change your coding habits to adhere to the SOLID principles more
directly and embrace TDD's ability to keep you honest.
2. Discard TDD and complain about how it makes you write really
complicated tests and wastes time.
The people I've seen choosing option 2 keep writing long methods and
big classes and keep producing code that is very difficult, and
sometimes impossible, for their teammates to understand, maintain and
enhance. Their productivity remains unchanged.
The people I've seen choosing option 1 are initially going slower
because they are retraining their mental programming muscles to
operate in a different fashion. After they build up their TDD
muscles, they end up moving faster than those that chose option 2
because they are able to produce code at the same quality faster
or better quality in the same time as those choosing option 2. Here
"time" has to be measured across design, develop, test and ship
lifecycle of a product/release and not just the "develop" part. The
empirical studies on TDD being introduced to teams show similar
results to what I've witnessed in my personal experience.
Don't like TDD? Fine, don't use it. I would suggest that you try it
for real before you decide that it has no merit. I've seen enough
people doing it wrong to know that it is difficult for some people to
understand what TDD is really asking them to do. It's less about the
physical tests than most people think.
Trying to convince me that TDD is a waste of time? You'll have to
show me how to achieve the same or better results with something else.
I've spent more years doing non-TDD development than I have spent
doing TDD. I have plenty of experience doing things both ways. My
experience has shown me and my immediately coworkers that TDD allows
us to ship better code with the same effort.
Obligatory comment for wood brain dead 77:
shitty shit, shit shit shit.
Wouter van Ooijen
Feb 17, 2016, 5:08:46 PM2/17/16
to
Op 17-Feb-16 om 10:08 PM schreef Richard:
than trying to convert Uncle Bob away from his rules. The chance of
success seems much higher.
The way he is talking he doesn't seem to have much experience in my main
field, which is low-level microcontroller embedded real-time
programming, so I don't regards his opinion as very relevant to me to
begin with, and his dogmatism doesn't make it any better.
Still, I think something like TDD can have some use for me in some
situations, but 'the three rules' when taken literally are (at least for
me) absurd. I like test, I like short code fragments (I don't use
classic OO, so I don't mention about classes or methods.) But I also
like to think, and write a bunch of test in one go, or a 100+ lines of
code in one go. The 'three rules' seem to rule that out (is that a
correct interpretation?) so anyone who thinks I should obey them
literally to be a professional is, as far as I am concerned, a joke.
Of course that doesn't rule out that the method works for some other
people. I never did much user interface stuff (I don't think I ever felt
the urge to use the MVC pattern, and I haven't touched a database for 30
years) so I am clearly in a different world than most of you :)
Wouter van Ooijen
> [Please do not mail me a copy of your followup]
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <56c4b474$0$4233$e4fe...@newszilla.xs4all.nl> thusly:
>
>> PS Uncle Bob *does* claim that TTD is *the* tool to apply to every
>> programming problem.
>
> What I've seen him claim is that he hasn't found anything better than
> TDD. If you can show him something better than TDD, then he'll be
> talking about that.
>
> If you have something you think is better than TDD, bring it Uncle Bob
> and get him to champion it. If you can convince Uncle Bob, I'm very
> interested in hearing about it.
I'd rather convert the pope to shintoism and the Bush family to atheism
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <56c4b474$0$4233$e4fe...@newszilla.xs4all.nl> thusly:
>
>> PS Uncle Bob *does* claim that TTD is *the* tool to apply to every
>> programming problem.
>
> What I've seen him claim is that he hasn't found anything better than
> TDD. If you can show him something better than TDD, then he'll be
> talking about that.
>
> If you have something you think is better than TDD, bring it Uncle Bob
> and get him to champion it. If you can convince Uncle Bob, I'm very
> interested in hearing about it.
than trying to convert Uncle Bob away from his rules. The chance of
success seems much higher.
The way he is talking he doesn't seem to have much experience in my main
field, which is low-level microcontroller embedded real-time
programming, so I don't regards his opinion as very relevant to me to
begin with, and his dogmatism doesn't make it any better.
Still, I think something like TDD can have some use for me in some
situations, but 'the three rules' when taken literally are (at least for
me) absurd. I like test, I like short code fragments (I don't use
classic OO, so I don't mention about classes or methods.) But I also
like to think, and write a bunch of test in one go, or a 100+ lines of
code in one go. The 'three rules' seem to rule that out (is that a
correct interpretation?) so anyone who thinks I should obey them
literally to be a professional is, as far as I am concerned, a joke.
Of course that doesn't rule out that the method works for some other
people. I never did much user interface stuff (I don't think I ever felt
the urge to use the MVC pattern, and I haven't touched a database for 30
years) so I am clearly in a different world than most of you :)
Wouter van Ooijen
Ian Collins
Feb 17, 2016, 5:19:49 PM2/17/16
to
Wouter van Ooijen wrote:
> Op 17-Feb-16 om 10:08 PM schreef Richard:
>> [Please do not mail me a copy of your followup]
>>
>> Wouter van Ooijen <wou...@voti.nl> spake the secret code
>> <56c4b474$0$4233$e4fe...@newszilla.xs4all.nl> thusly:
>>
>>> PS Uncle Bob *does* claim that TTD is *the* tool to apply to every
>>> programming problem.
>>
>> What I've seen him claim is that he hasn't found anything better than
>> TDD. If you can show him something better than TDD, then he'll be
>> talking about that.
>>
>> If you have something you think is better than TDD, bring it Uncle Bob
>> and get him to champion it. If you can convince Uncle Bob, I'm very
>> interested in hearing about it.
>
> I'd rather convert the pope to shintoism and the Bush family to atheism
> than trying to convert Uncle Bob away from his rules. The chance of
> success seems much higher.
>
> The way he is talking he doesn't seem to have much experience in my main
> field, which is low-level microcontroller embedded real-time
> programming, so I don't regards his opinion as very relevant to me to
> begin with, and his dogmatism doesn't make it any better.
My first XP (hence TDD) projects were low-level microcontroller embedded
> Op 17-Feb-16 om 10:08 PM schreef Richard:
>> [Please do not mail me a copy of your followup]
>>
>> Wouter van Ooijen <wou...@voti.nl> spake the secret code
>> <56c4b474$0$4233$e4fe...@newszilla.xs4all.nl> thusly:
>>
>>> PS Uncle Bob *does* claim that TTD is *the* tool to apply to every
>>> programming problem.
>>
>> What I've seen him claim is that he hasn't found anything better than
>> TDD. If you can show him something better than TDD, then he'll be
>> talking about that.
>>
>> If you have something you think is better than TDD, bring it Uncle Bob
>> and get him to champion it. If you can convince Uncle Bob, I'm very
>> interested in hearing about it.
>
> I'd rather convert the pope to shintoism and the Bush family to atheism
> than trying to convert Uncle Bob away from his rules. The chance of
> success seems much higher.
>
> The way he is talking he doesn't seem to have much experience in my main
> field, which is low-level microcontroller embedded real-time
> programming, so I don't regards his opinion as very relevant to me to
> begin with, and his dogmatism doesn't make it any better.
real-time as was my most recent...
> Still, I think something like TDD can have some use for me in some
> situations, but 'the three rules' when taken literally are (at least for
> me) absurd. I like test, I like short code fragments (I don't use
> classic OO, so I don't mention about classes or methods.) But I also
> like to think, and write a bunch of test in one go, or a 100+ lines of
> code in one go. The 'three rules' seem to rule that out (is that a
> correct interpretation?) so anyone who thinks I should obey them
> literally to be a professional is, as far as I am concerned, a joke.
I certainly do and for such low level fiddly code I find TDD to be an
ideal tool. I like to step through, almost bit by bit, tasks such as
setting up device registers. The steps, both conceptually and in code,
are small and ideally suited to an incremental test/code/refactor cycle
such as TDD. Being close to a pure coding exercise, any objections to
TDD and design are irrelevant at this level.
--
Ian Collins
Wouter van Ooijen
Feb 18, 2016, 2:33:33 AM2/18/16
to
Op 17-Feb-16 om 11:19 PM schreef Ian Collins:
Let's say I write code for a UART to transmit data at a (run-time)
specified baudrate. What would your (first) test be?
Wouter
specified baudrate. What would your (first) test be?
Wouter
Ian Collins
Feb 18, 2016, 2:43:06 AM2/18/16
to
Wouter van Ooijen wrote:
> Op 17-Feb-16 om 11:19 PM schreef Ian Collins:
>>
> Op 17-Feb-16 om 11:19 PM schreef Ian Collins:
>>
>> Let me ask you why you wouldn't obey the rules for say a device driver?
>> I certainly do and for such low level fiddly code I find TDD to be an
>> ideal tool. I like to step through, almost bit by bit, tasks such as
>> setting up device registers. The steps, both conceptually and in code,
>> are small and ideally suited to an incremental test/code/refactor cycle
>> such as TDD. Being close to a pure coding exercise, any objections to
>> TDD and design are irrelevant at this level.
>
> Let's say I write code for a UART to transmit data at a (run-time)
> specified baudrate. What would your (first) test be?
It wouldn't be the first test (there would be more generic configuration
>> I certainly do and for such low level fiddly code I find TDD to be an
>> ideal tool. I like to step through, almost bit by bit, tasks such as
>> setting up device registers. The steps, both conceptually and in code,
>> are small and ideally suited to an incremental test/code/refactor cycle
>> such as TDD. Being close to a pure coding exercise, any objections to
>> TDD and design are irrelevant at this level.
>
> Let's say I write code for a UART to transmit data at a (run-time)
> specified baudrate. What would your (first) test be?
to test first), but the last test for the requirement would be that the
drive sits the correct bits in the the appropriate configuration
register(s).
--
Ian Collins
Ian Collins
Feb 18, 2016, 2:45:20 AM2/18/16
to
> register(s).
--
Ian Collins
Wouter van Ooijen
Feb 18, 2016, 2:58:23 AM2/18/16
to
Op 18-Feb-16 om 8:42 AM schreef Ian Collins:
> but the last test for the requirement would be that the
> drive sits the correct bits in the the appropriate configuration
> register(s).
But how do you determine what is the correct setting (or: how do you
make sure that the settings you have determined have the desired effect)?
Wouter
> Wouter van Ooijen wrote:
>> Op 17-Feb-16 om 11:19 PM schreef Ian Collins:
>>>
>>> Let me ask you why you wouldn't obey the rules for say a device driver?
>>> I certainly do and for such low level fiddly code I find TDD to be an
>>> ideal tool. I like to step through, almost bit by bit, tasks such as
>>> setting up device registers. The steps, both conceptually and in code,
>>> are small and ideally suited to an incremental test/code/refactor cycle
>>> such as TDD. Being close to a pure coding exercise, any objections to
>>> TDD and design are irrelevant at this level.
>>
>> Let's say I write code for a UART to transmit data at a (run-time)
>> specified baudrate. What would your (first) test be?
>
> It wouldn't be the first test (there would be more generic configuration
> to test first),
such as?
>> Op 17-Feb-16 om 11:19 PM schreef Ian Collins:
>>>
>>> Let me ask you why you wouldn't obey the rules for say a device driver?
>>> I certainly do and for such low level fiddly code I find TDD to be an
>>> ideal tool. I like to step through, almost bit by bit, tasks such as
>>> setting up device registers. The steps, both conceptually and in code,
>>> are small and ideally suited to an incremental test/code/refactor cycle
>>> such as TDD. Being close to a pure coding exercise, any objections to
>>> TDD and design are irrelevant at this level.
>>
>> Let's say I write code for a UART to transmit data at a (run-time)
>> specified baudrate. What would your (first) test be?
>
> It wouldn't be the first test (there would be more generic configuration
> to test first),
> but the last test for the requirement would be that the
> drive sits the correct bits in the the appropriate configuration
> register(s).
make sure that the settings you have determined have the desired effect)?
Wouter
Wouter van Ooijen
Feb 18, 2016, 2:58:48 AM2/18/16
to
Op 18-Feb-16 om 8:45 AM schreef Ian Collins:
9:00 here, a fresh day just started :)
Wouter
Wouter
Ian Collins
Feb 18, 2016, 3:18:03 AM2/18/16
to
Wouter van Ooijen wrote:
> Op 18-Feb-16 om 8:42 AM schreef Ian Collins:
>> Wouter van Ooijen wrote:
>>> Op 17-Feb-16 om 11:19 PM schreef Ian Collins:
>>>>
>>>> Let me ask you why you wouldn't obey the rules for say a device driver?
>>>> I certainly do and for such low level fiddly code I find TDD to be an
>>>> ideal tool. I like to step through, almost bit by bit, tasks such as
>>>> setting up device registers. The steps, both conceptually and in code,
>>>> are small and ideally suited to an incremental test/code/refactor cycle
>>>> such as TDD. Being close to a pure coding exercise, any objections to
>>>> TDD and design are irrelevant at this level.
>>>
>>> Let's say I write code for a UART to transmit data at a (run-time)
>>> specified baudrate. What would your (first) test be?
>>
>> It wouldn't be the first test (there would be more generic configuration
>> to test first),
>
> such as?
That depends on the device, if the UART is stand alone, there might not
> Op 18-Feb-16 om 8:42 AM schreef Ian Collins:
>> Wouter van Ooijen wrote:
>>> Op 17-Feb-16 om 11:19 PM schreef Ian Collins:
>>>>
>>>> Let me ask you why you wouldn't obey the rules for say a device driver?
>>>> I certainly do and for such low level fiddly code I find TDD to be an
>>>> ideal tool. I like to step through, almost bit by bit, tasks such as
>>>> setting up device registers. The steps, both conceptually and in code,
>>>> are small and ideally suited to an incremental test/code/refactor cycle
>>>> such as TDD. Being close to a pure coding exercise, any objections to
>>>> TDD and design are irrelevant at this level.
>>>
>>> Let's say I write code for a UART to transmit data at a (run-time)
>>> specified baudrate. What would your (first) test be?
>>
>> It wouldn't be the first test (there would be more generic configuration
>> to test first),
>
> such as?
be any but if it is part of a processor, there will probably
configuration registers that have to be setup before the UART can be used.
>> but the last test for the requirement would be that the
>> drive sits the correct bits in the the appropriate configuration
>> register(s).
>
> But how do you determine what is the correct setting (or: how do you
> make sure that the settings you have determined have the desired effect)?
I actually wrote tests for a UART driver on an ARM STM32 processor last
year. To verify the settings I had a block of mapped memory at the
appropriate address for the device registers and simply tested for the
correct values getting written.
--
Ian Collins
Wouter van Ooijen
Feb 18, 2016, 3:22:09 AM2/18/16
to
Op 18-Feb-16 om 9:17 AM schreef Ian Collins:
Of course, but how do you verify that you derived the correct (and
complete) conclusions from the device specification? In my experience
*that* is where the errors can be made! (I often make errors - or rather
omissions - in that aspect. I don't recall ever making an error afer
that: once the correct values are determined writing them is trivial.)
Wouter
complete) conclusions from the device specification? In my experience
*that* is where the errors can be made! (I often make errors - or rather
omissions - in that aspect. I don't recall ever making an error afer
that: once the correct values are determined writing them is trivial.)
Wouter
Ian Collins
Feb 18, 2016, 3:24:25 AM2/18/16
to
void
TestUART::testConstructDeviceOneAssignsCorrectBaudRateDivider()
{
const auto baudRate = 100;
const auto clockFrequency = 1000;
test::STM32F3xxuPClockDriver_GetClock::willReturn(clockFrequency);
STM32F3xxUARTDriver( STM32F3xxUARTDriver::USARTPort1, nullptr, 0,
baudRate );
TS_ASSERT_EQUALS( clockFrequency/baudRate, usart1->BRR );
}
test::STM32F3xxuPClockDriver_GetClock is a mock for another interface,
usart1 is an address defined in one of the headers.
--
Ian Collins
Ian Collins
Feb 18, 2016, 3:28:18 AM2/18/16
to
spike build that validated our understanding of the real hardware.
Oh and did I mention pair programming? That's be best way of avoiding
those silly errors!
--
Ian Collins
Wouter van Ooijen
Feb 18, 2016, 3:39:31 AM2/18/16
to
Op 18-Feb-16 om 9:28 AM schreef Ian Collins:
Now that the test I would start with.
Note that I mentioned 'run-time specified baudrate'. Would you test
(whether register-values-based or with real hardware) be for one
specific baudrate? And would the code you write be for one baudrate only
or for the allowed range?
Wouter
Note that I mentioned 'run-time specified baudrate'. Would you test
(whether register-values-based or with real hardware) be for one
specific baudrate? And would the code you write be for one baudrate only
or for the allowed range?
Wouter
Ian Collins
Feb 18, 2016, 5:22:55 AM2/18/16
to
Wouter van Ooijen wrote:
>
> Note that I mentioned 'run-time specified baudrate'. Would you test
> (whether register-values-based or with real hardware) be for one
> specific baudrate? And would the code you write be for one baudrate only
> or for the allowed range?
Now that is really hard to answer, there are so many ifs buts and
>
> Note that I mentioned 'run-time specified baudrate'. Would you test
> (whether register-values-based or with real hardware) be for one
> specific baudrate? And would the code you write be for one baudrate only
> or for the allowed range?
maybes! In the example I cited, there was only one baud rate, so we
only had to test that the correct number was written to the register.
if there were several discrete values, how many to test would depend on
how the value was derived.
I would probably test the setting of the register and the the algorithm
used to calculate the value. The algorithm is just like any other and
not specifically driver/embedded code code.
Either way my point - that TDD is just as relevant and useful for low
level embedded code as it is for business logic - still stands. Code is
code. How you implement the details of the tests may vary, but the
process does not.
--
Ian Collins
Ian Collins
Feb 18, 2016, 5:24:58 AM2/18/16
to
Wouter van Ooijen wrote:
> Op 18-Feb-16 om 8:45 AM schreef Ian Collins:
>>
> Op 18-Feb-16 om 8:45 AM schreef Ian Collins:
>>
>> It's been a long day... s/drive sits/driver sets/
>
> 9:00 here, a fresh day just started :)
23:23 here, time to leave the Linux kernel bugs to fester until morning!
>
> 9:00 here, a fresh day just started :)
--
Ian Collins
Wouter van Ooijen
Feb 18, 2016, 5:58:04 AM2/18/16
to
Op 18-Feb-16 om 11:22 AM schreef Ian Collins:
Some messages ago you said that you follow the 3 rules, I am trying to
find how you do that in a meaningfull way. Rule 2 says
"You are not allowed to write any more of a unit test than is sufficient
to fail."
And 3 says
"You are not allowed to write any more production code than is
sufficient to pass the one failing unit test."
IMO whenever you add a new baudrate to the set suite, the simplest way
to make that test pass is to add an if statement or maybe a switch case
or a table entry. Writing a formula that calculates the settings from
the baudrate is more complex (reequires more code), so doing that
violates rule 3?
Wouter
find how you do that in a meaningfull way. Rule 2 says
"You are not allowed to write any more of a unit test than is sufficient
to fail."
And 3 says
"You are not allowed to write any more production code than is
sufficient to pass the one failing unit test."
IMO whenever you add a new baudrate to the set suite, the simplest way
to make that test pass is to add an if statement or maybe a switch case
or a table entry. Writing a formula that calculates the settings from
the baudrate is more complex (reequires more code), so doing that
violates rule 3?
Wouter
Richard
Feb 18, 2016, 12:49:05 PM2/18/16
to
[Please do not mail me a copy of your followup]
Wouter van Ooijen <wou...@voti.nl> spake the secret code
<56c4ef61$0$4197$e4fe...@newszilla.xs4all.nl> thusly:
Wouter van Ooijen <wou...@voti.nl> spake the secret code
>Op 17-Feb-16 om 10:08 PM schreef Richard:
>> [Please do not mail me a copy of your followup]
>>
>> Wouter van Ooijen <wou...@voti.nl> spake the secret code
>> <56c4b474$0$4233$e4fe...@newszilla.xs4all.nl> thusly:
>>
>>> PS Uncle Bob *does* claim that TTD is *the* tool to apply to every
>>> programming problem.
>>
>> What I've seen him claim is that he hasn't found anything better than
>> TDD. If you can show him something better than TDD, then he'll be
>> talking about that.
>>
>> If you have something you think is better than TDD, bring it Uncle Bob
>> and get him to champion it. If you can convince Uncle Bob, I'm very
>> interested in hearing about it.
>
Three words in and we're already into a straw man.
You present an opinion that is against TDD and you put words in Uncle
Bob's mouth so that you can conveniently make him out to be a zealout
and demolish the straw man.
When I point out that Uncle Bob is adopting a position based on
evidence and experience (not just his, but the experience of many
people), you invent another straw man turning it into a religious
debate.
Positions adopted based on evidence and supporting experience (the team
at IBM, the team at MS, etc.) are not religious positions.
When I see you respond this way, it makes you out to be the religious
zealout, not Uncle Bob.
Wouter van Ooijen
Feb 18, 2016, 1:04:16 PM2/18/16
to
Op 18-Feb-16 om 6:48 PM schreef Richard:
in?), I just expressed (in a tongue-in-cheeck way) that I don't have
much faith in converting him.
Maybe more interesting is what I wrote after that fragment: I don't like
the three rules when they are interpreted literally. The few talks by
Uncle Bob that I have seen seem to indicate that he does.
In the follow up I had a reasonable discussion with Ian, which we will
probably continue when our timezones permit it. If you want to
contribute to the real discussion you are welcome.
My main pain point is that to me the rules seem to force me to write
only one failing test case, and then just correct the code to pass that
case. Other people talk about refactoring, but the three rules don't
mention that, so following the 3 rules (and only the 3 rules, as Bob
repeatly states in his talks) religiously seems (to me) to rule out
refactoring, which seems absurd to me.
Wouter van Ooijen
> [Please do not mail me a copy of your followup]
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <56c4ef61$0$4197$e4fe...@newszilla.xs4all.nl> thusly:
>
>> Op 17-Feb-16 om 10:08 PM schreef Richard:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Wouter van Ooijen <wou...@voti.nl> spake the secret code
>>> <56c4b474$0$4233$e4fe...@newszilla.xs4all.nl> thusly:
>>>
>>>> PS Uncle Bob *does* claim that TTD is *the* tool to apply to every
>>>> programming problem.
>>>
>>> What I've seen him claim is that he hasn't found anything better than
>>> TDD. If you can show him something better than TDD, then he'll be
>>> talking about that.
>>>
>>> If you have something you think is better than TDD, bring it Uncle Bob
>>> and get him to champion it. If you can convince Uncle Bob, I'm very
>>> interested in hearing about it.
>>
>> I'd rather convert [...]
>
> Three words in and we're already into a straw man.
>
> You present an opinion that is against TDD and you put words in Uncle
> Bob's mouth so that you can conveniently make him out to be a zealout
> and demolish the straw man.
I did not put any words in his mouth (can you quote any that I did put
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <56c4ef61$0$4197$e4fe...@newszilla.xs4all.nl> thusly:
>
>> Op 17-Feb-16 om 10:08 PM schreef Richard:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Wouter van Ooijen <wou...@voti.nl> spake the secret code
>>> <56c4b474$0$4233$e4fe...@newszilla.xs4all.nl> thusly:
>>>
>>>> PS Uncle Bob *does* claim that TTD is *the* tool to apply to every
>>>> programming problem.
>>>
>>> What I've seen him claim is that he hasn't found anything better than
>>> TDD. If you can show him something better than TDD, then he'll be
>>> talking about that.
>>>
>>> If you have something you think is better than TDD, bring it Uncle Bob
>>> and get him to champion it. If you can convince Uncle Bob, I'm very
>>> interested in hearing about it.
>>
>> I'd rather convert [...]
>
> Three words in and we're already into a straw man.
>
> You present an opinion that is against TDD and you put words in Uncle
> Bob's mouth so that you can conveniently make him out to be a zealout
> and demolish the straw man.
in?), I just expressed (in a tongue-in-cheeck way) that I don't have
much faith in converting him.
Maybe more interesting is what I wrote after that fragment: I don't like
the three rules when they are interpreted literally. The few talks by
Uncle Bob that I have seen seem to indicate that he does.
In the follow up I had a reasonable discussion with Ian, which we will
probably continue when our timezones permit it. If you want to
contribute to the real discussion you are welcome.
My main pain point is that to me the rules seem to force me to write
only one failing test case, and then just correct the code to pass that
case. Other people talk about refactoring, but the three rules don't
mention that, so following the 3 rules (and only the 3 rules, as Bob
repeatly states in his talks) religiously seems (to me) to rule out
refactoring, which seems absurd to me.
Wouter van Ooijen
Ian Collins
Feb 18, 2016, 3:29:45 PM2/18/16
to
any stage and know that you haven't broken it is one of the benefits of
the process. So yes, you might start off with a chain of ifs and then
go back and change the code to use a better algorithm.
That's OK, that's good. One of the biggest problems I see with people
new to TDD is that they done do what I consider the most important step
- refactoring. So they end up with the messy code TDD's detractors
complain about.
Write a test
Pass the test
Commit
Refactor
Commit
--
Ian Collins
Wouter van Ooijen
Feb 18, 2016, 4:00:56 PM2/18/16
to
Op 18-Feb-16 om 9:29 PM schreef Ian Collins:
Rule 3 at http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd is
Wouter
"You are not allowed to write any more production code than is
sufficient to pass the one failing unit test."
In your opinion, does that include refactoring?
sufficient to pass the one failing unit test."
Wouter
Ian Collins
Feb 18, 2016, 4:11:06 PM2/18/16
to
"You are not allowed to add functionality to any production code than is
sufficient to pass the one failing unit test."
Or even
"You are not allowed to change the visible behaviour of any production
code than is sufficient to pass the one failing unit test."
Although that may be a bit too vague.
I prefer to teach the write a test, pass the test cycle as adding
functionality rather than adding code. Code is too specific in my
opinion: you might add functionality by removing code!
--
Ian Collins
Vir Campestris
Feb 18, 2016, 4:27:35 PM2/18/16
to
On 17/02/2016 22:19, Ian Collins wrote:
> Let me ask you why you wouldn't obey the rules for say a device driver?
> I certainly do and for such low level fiddly code I find TDD to be an
> ideal tool. I like to step through, almost bit by bit, tasks such as
> setting up device registers. The steps, both conceptually and in code,
> are small and ideally suited to an incremental test/code/refactor cycle
> such as TDD. Being close to a pure coding exercise, any objections to
> TDD and design are irrelevant at this level.
I'm working on an ALSA driver for an embedded device at the moment.
> Let me ask you why you wouldn't obey the rules for say a device driver?
> I certainly do and for such low level fiddly code I find TDD to be an
> ideal tool. I like to step through, almost bit by bit, tasks such as
> setting up device registers. The steps, both conceptually and in code,
> are small and ideally suited to an incremental test/code/refactor cycle
> such as TDD. Being close to a pure coding exercise, any objections to
> TDD and design are irrelevant at this level.
I can't find any decent specs, the hardware doesn't seem to quite
behave, and the calls from the kernel are... odd.
I have a slight feeling that the whole of Linux was thrown together by a
bunch of hackers (good ones) and that the kernel for my device has been
changed by other hackers. None of them wrote down what they were
intending to do, so when I look at different drivers that do things in
different ways I can't really tell which is the new way, and which the old.
I can't really write any tests at all - I can't really tell what it's
supposed to do, beyond make a noise. And since the I2S DMA is broken
that's a long way off.
Andy
Vir Campestris
Feb 18, 2016, 4:30:26 PM2/18/16
to
On 17/02/2016 11:26, Juha Nieminen wrote:
> I don't think anybody (who knows anything) is claiming that TDD is
> the silver bullet, the perfect tool for every possible situation.
Extreme Programming. (We did the training course - then decided not to
do it)
Andy
> I don't think anybody (who knows anything) is claiming that TDD is
> the silver bullet, the perfect tool for every possible situation.
Extreme Programming. (We did the training course - then decided not to
do it)
Andy
Wouter van Ooijen
Feb 18, 2016, 5:16:02 PM2/18/16
to
Op 18-Feb-16 om 10:10 PM schreef Ian Collins:
OK, so I think we agree that taking that Uncle Bob page literally is not
a good idea?
Can you refer me to a page or document or whatever that describes the
version of TDD that you find usefull?
==================
And back to the UART :)
After the first test case, would I be allowed to write the UART init
code that calculates the settings from the specified baudrate? That is
much more than needed to pass that single test (which is for one
baudrate). The TDD demo's that I have seen specifically don't do that.
Wouter
a good idea?
Can you refer me to a page or document or whatever that describes the
version of TDD that you find usefull?
==================
And back to the UART :)
After the first test case, would I be allowed to write the UART init
code that calculates the settings from the specified baudrate? That is
much more than needed to pass that single test (which is for one
baudrate). The TDD demo's that I have seen specifically don't do that.
Wouter
Ian Collins
Feb 19, 2016, 5:22:50 PM2/19/16
to
Wouter van Ooijen wrote:
> Op 18-Feb-16 om 10:10 PM schreef Ian Collins:
> Op 18-Feb-16 om 10:10 PM schreef Ian Collins:
>> I prefer to teach the write a test, pass the test cycle as adding
>> functionality rather than adding code. Code is too specific in my
>> opinion: you might add functionality by removing code!
>
> OK, so I think we agree that taking that Uncle Bob page literally is not
> a good idea?
Taking anything related to Agile practices too literally isn't a good
>> functionality rather than adding code. Code is too specific in my
>> opinion: you might add functionality by removing code!
>
> OK, so I think we agree that taking that Uncle Bob page literally is not
> a good idea?
idea! Doing so goes against the underlying people over process
philosophy of agile.
The "rules" laid down by the well known agile evangelists should be
interpreted as guidelines rather than strict process steps (like those
mandated by RUP). Look on them as somewhere to start the development of
your own process. Every agile team I know have their own modified
processes, some of these go back well before the "agile boom" in the
early 2000s.
> Can you refer me to a page or document or whatever that describes the
> version of TDD that you find usefull?
conference back in 2002 and realised it put a more formal structure
around the way I had been working for years. My then team developed our
own process based on the concepts we had learned at the conference.
Learning how to use agile processes isn't easy on your own, the long
standing advice is to hire a coach for the first few weeks or months
(depending on your budget). You really do have to learn by doing.
> ==================
>
> And back to the UART :)
>
> After the first test case, would I be allowed to write the UART init
> code that calculates the settings from the specified baudrate?
--
Ian Collins
Richard
Feb 19, 2016, 5:40:03 PM2/19/16
to
[Please do not mail me a copy of your followup]
Ian Collins <ian-...@hotmail.com> spake the secret code
<dipisv...@mid.individual.net> thusly:
>The "rules" laid down by the well known agile evangelists should be
>interpreted as guidelines rather than strict process steps (like those
>mandated by RUP).
of TDD you should *literally* do them when learning TDD. You should
obey those rules literally and without deviation. Doing so is crucial
to learning TDD and actually "getting it" IMO.
You'll know you're in a good TDD workshop when the instructor reviews
the code of students and tells them to delete everything they've done
and start over when they've violated the rules.
In martial arts, this is known as "shuhari". When you are beginning
to learn TDD you aren't yet masterful enough to know *when* you can
bend or break the rules, so you must follow them rigidly. (You are
"shu".) As you achieve mastery, you advance to "ha" where you can
start to bend the rules or even break them completely. When you
become a true master, you advance to "ri" and the rules are no longer
necessary because you've internalized them as habit and you can be
more expressive and freeform or even make up your own competing
system.
<https://en.wikipedia.org/wiki/Shuhari>
Many of the people I've seen struggle with TDD are programmers with
many years of experience outside of TDD that feel uncomfortable being
placed into a position where they have to rigidly follow the rules
because they haven't achieved mastery.
This is somewhat akin to saying:
"What's so hard about programming? It's just typing!"
From what I can tell, Ian has been doing this a while and he has a
good intuition for when he can bend the rules without getting himself
into trouble. For an absolute beginner, it is my opinion that they
follow the rules literally. Otherwise, they will miss the crucial
insight that TDD brings because they will keep doing things the old
way.
I describe TDD as turning your normal pyramid of development upside
down. It is a significantly different way of thinking about the code
development process.
Wouter van Ooijen
Feb 19, 2016, 6:21:11 PM2/19/16
to
Op 19-Feb-16 om 11:39 PM schreef Richard:
I think I am a rather good programmer / system designer (don't we all
think we are?) and I decide for myself what I find usefull. There are
lots of development processes available, and I can't 'walk' them all, so
I'll have to choose, upfront, based on what I see, waht is worth trying.
You (Richard) and Ian present two rather different views of what you
think TDD is (or should be). Based on what you say, and a few Uncle Bob
talks, I reject the Bob/Richard path as rediculous, but the
Ian/Kent-Beck path might be interesting. I'll watch a few Kent Beck
talks before I decide.
Wouter van Ooijen
think we are?) and I decide for myself what I find usefull. There are
lots of development processes available, and I can't 'walk' them all, so
I'll have to choose, upfront, based on what I see, waht is worth trying.
You (Richard) and Ian present two rather different views of what you
think TDD is (or should be). Based on what you say, and a few Uncle Bob
talks, I reject the Bob/Richard path as rediculous, but the
Ian/Kent-Beck path might be interesting. I'll watch a few Kent Beck
talks before I decide.
Wouter van Ooijen
Ian Collins
Feb 19, 2016, 7:16:16 PM2/19/16
to
Wouter van Ooijen wrote:
> Op 19-Feb-16 om 11:39 PM schreef Richard:
>> [Please do not mail me a copy of your followup]
>>
>> Ian Collins <ian-...@hotmail.com> spake the secret code
>> <dipisv...@mid.individual.net> thusly:
>>
>>> The "rules" laid down by the well known agile evangelists should be
>>> interpreted as guidelines rather than strict process steps (like those
>>> mandated by RUP).
>>
>> Instead of generalizing, I'm going to say that for Uncle Bob's rules
>> of TDD you should *literally* do them when learning TDD. You should
>> obey those rules literally and without deviation. Doing so is crucial
>> to learning TDD and actually "getting it" IMO.
>>
<snip>
> Op 19-Feb-16 om 11:39 PM schreef Richard:
>> [Please do not mail me a copy of your followup]
>>
>> Ian Collins <ian-...@hotmail.com> spake the secret code
>> <dipisv...@mid.individual.net> thusly:
>>
>>> The "rules" laid down by the well known agile evangelists should be
>>> interpreted as guidelines rather than strict process steps (like those
>>> mandated by RUP).
>>
>> Instead of generalizing, I'm going to say that for Uncle Bob's rules
>> of TDD you should *literally* do them when learning TDD. You should
>> obey those rules literally and without deviation. Doing so is crucial
>> to learning TDD and actually "getting it" IMO.
>>
> I think I am a rather good programmer / system designer (don't we all
> think we are?) and I decide for myself what I find usefull. There are
> lots of development processes available, and I can't 'walk' them all, so
> I'll have to choose, upfront, based on what I see, waht is worth trying.
> You (Richard) and Ian present two rather different views of what you
> think TDD is (or should be).
with Richard that strict adherence to the rules is important in a
teaching environment, whether they be learning a process or anything else.
Things were a little different for us when we starting down the XP path.
There weren't any coaches or formal training here at the time, we were
early adopters so we had to find our own way on a real project. We
probably took way longer than if we had had outside support, but we were
happy with the end result. I think we would have failed if we had tried
to do things by the book because we wouldn't have had a good enough
understanding of it! I would probably have had a revolt on my hands...
The martial arts analogy is a good one, although I prefer to think of a
development team as a herd of elephants and a good coach as the
matriarch. We didn't have a matriarch, so we blundered around a bit.
But we found the water in the end...
> Based on what you say, and a few Uncle Bob
> talks, I reject the Bob/Richard path as rediculous, but the
> Ian/Kent-Beck path might be interesting. I'll watch a few Kent Beck
> talks before I decide.
one that fits your way of working.
--
Ian Collins
Wouter van Ooijen
Feb 20, 2016, 3:07:48 AM2/20/16
to
Op 20-Feb-16 om 1:16 AM schreef Ian Collins:
that Richard wants to be followed strictly *exclude* refactoring, while
Ians rules *include* it. For me that's the difference between night and day.
I don't believe in doing it differently while learning than while doing
actual work. That is OK for muscle work (wax on, wax off), or for
accosciative creativity (which is almost muscle work), but not for
thinking processes. For me, any method that, while in the learning
phase, can't or doesn't want to explain and defend the steps (or absense
of steps!) in terms of the end goal is out. I am not a child, and
neither are my students.
Richard, the same UART case for you: I must write a UART baudrate
initialization. The method accepts a run-time specified baudrate. Strict
3-rule TDD keeps me in the cycle
- write test case (for a specific baudrate)
- adapt code to pass that case
This leads to code that has a list of if's or equivalent. It passes all
the tests, but it is crappy code. Now Ian says: refactor! You seem to
say: no, don't do that. So how does your process lead me to good code?
Wouter van Ooijen
> Wouter van Ooijen wrote:
>> Op 19-Feb-16 om 11:39 PM schreef Richard:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Ian Collins <ian-...@hotmail.com> spake the secret code
>>> <dipisv...@mid.individual.net> thusly:
>>>
>>>> The "rules" laid down by the well known agile evangelists should be
>>>> interpreted as guidelines rather than strict process steps (like those
>>>> mandated by RUP).
>>>
>>> Instead of generalizing, I'm going to say that for Uncle Bob's rules
>>> of TDD you should *literally* do them when learning TDD. You should
>>> obey those rules literally and without deviation. Doing so is crucial
>>> to learning TDD and actually "getting it" IMO.
>>>
>
> <snip>
>
>> I think I am a rather good programmer / system designer (don't we all
>> think we are?) and I decide for myself what I find usefull. There are
>> lots of development processes available, and I can't 'walk' them all, so
>> I'll have to choose, upfront, based on what I see, waht is worth trying.
>> You (Richard) and Ian present two rather different views of what you
>> think TDD is (or should be).
>
> I don't think there is as big a difference as you make out. I agree
> with Richard that strict adherence to the rules is important in a
> teaching environment, whether they be learning a process or anything else.
But, as I understand (both of you, correct me if I am wrong) the rules
>> Op 19-Feb-16 om 11:39 PM schreef Richard:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Ian Collins <ian-...@hotmail.com> spake the secret code
>>> <dipisv...@mid.individual.net> thusly:
>>>
>>>> The "rules" laid down by the well known agile evangelists should be
>>>> interpreted as guidelines rather than strict process steps (like those
>>>> mandated by RUP).
>>>
>>> Instead of generalizing, I'm going to say that for Uncle Bob's rules
>>> of TDD you should *literally* do them when learning TDD. You should
>>> obey those rules literally and without deviation. Doing so is crucial
>>> to learning TDD and actually "getting it" IMO.
>>>
>
> <snip>
>
>> I think I am a rather good programmer / system designer (don't we all
>> think we are?) and I decide for myself what I find usefull. There are
>> lots of development processes available, and I can't 'walk' them all, so
>> I'll have to choose, upfront, based on what I see, waht is worth trying.
>> You (Richard) and Ian present two rather different views of what you
>> think TDD is (or should be).
>
> I don't think there is as big a difference as you make out. I agree
> with Richard that strict adherence to the rules is important in a
> teaching environment, whether they be learning a process or anything else.
that Richard wants to be followed strictly *exclude* refactoring, while
Ians rules *include* it. For me that's the difference between night and day.
I don't believe in doing it differently while learning than while doing
actual work. That is OK for muscle work (wax on, wax off), or for
accosciative creativity (which is almost muscle work), but not for
thinking processes. For me, any method that, while in the learning
phase, can't or doesn't want to explain and defend the steps (or absense
of steps!) in terms of the end goal is out. I am not a child, and
neither are my students.
Richard, the same UART case for you: I must write a UART baudrate
initialization. The method accepts a run-time specified baudrate. Strict
3-rule TDD keeps me in the cycle
- write test case (for a specific baudrate)
- adapt code to pass that case
This leads to code that has a list of if's or equivalent. It passes all
the tests, but it is crappy code. Now Ian says: refactor! You seem to
say: no, don't do that. So how does your process lead me to good code?
Wouter van Ooijen
Ian Collins
Feb 20, 2016, 3:17:39 AM2/20/16
to
Wouter van Ooijen wrote:
> Op 20-Feb-16 om 1:16 AM schreef Ian Collins:
>> Wouter van Ooijen wrote:
>>
>>> I think I am a rather good programmer / system designer (don't we all
>>> think we are?) and I decide for myself what I find usefull. There are
>>> lots of development processes available, and I can't 'walk' them all, so
>>> I'll have to choose, upfront, based on what I see, waht is worth trying.
>>> You (Richard) and Ian present two rather different views of what you
>>> think TDD is (or should be).
>>
>> I don't think there is as big a difference as you make out. I agree
>> with Richard that strict adherence to the rules is important in a
>> teaching environment, whether they be learning a process or anything else.
>
> But, as I understand (both of you, correct me if I am wrong) the rules
> that Richard wants to be followed strictly *exclude* refactoring, while
> Ians rules *include* it. For me that's the difference between night and day.
Someone must be misinterpreting something here, TDD without refactoring
> Op 20-Feb-16 om 1:16 AM schreef Ian Collins:
>> Wouter van Ooijen wrote:
>>
>>> I think I am a rather good programmer / system designer (don't we all
>>> think we are?) and I decide for myself what I find usefull. There are
>>> lots of development processes available, and I can't 'walk' them all, so
>>> I'll have to choose, upfront, based on what I see, waht is worth trying.
>>> You (Richard) and Ian present two rather different views of what you
>>> think TDD is (or should be).
>>
>> I don't think there is as big a difference as you make out. I agree
>> with Richard that strict adherence to the rules is important in a
>> teaching environment, whether they be learning a process or anything else.
>
> But, as I understand (both of you, correct me if I am wrong) the rules
> that Richard wants to be followed strictly *exclude* refactoring, while
> Ians rules *include* it. For me that's the difference between night and day.
is like a burger without a bun: messy!
> I don't believe in doing it differently while learning than while doing
> actual work.
know what is safe to leave out? If you were learning to fly from a
book, would you disregard sections you don't like?
> That is OK for muscle work (wax on, wax off), or for
> accosciative creativity (which is almost muscle work), but not for
> thinking processes. For me, any method that, while in the learning
> phase, can't or doesn't want to explain and defend the steps (or absense
> of steps!) in terms of the end goal is out. I am not a child, and
> neither are my students.
earlier point - hire a coach.
> Richard, the same UART case for you: I must write a UART baudrate
> initialization. The method accepts a run-time specified baudrate. Strict
> 3-rule TDD keeps me in the cycle
>
> - write test case (for a specific baudrate)
> - adapt code to pass that case
>
> This leads to code that has a list of if's or equivalent. It passes all
> the tests, but it is crappy code. Now Ian says: refactor! You seem to
> say: no, don't do that. So how does your process lead me to good code?
Richard disagreed.
--
Ian Collins
Wouter van Ooijen
Feb 20, 2016, 3:53:09 AM2/20/16
to
Op 20-Feb-16 om 9:17 AM schreef Ian Collins:
Yes. A better comparison would be learning to fly a simulator, because
doing something wrong writing (my own) software will not kill me. If I
get killed in the simulated fligts I will reconsider my opinion of the
sections I disregarded.
>> That is OK for muscle work (wax on, wax off), or for
>> accosciative creativity (which is almost muscle work), but not for
>> thinking processes. For me, any method that, while in the learning
>> phase, can't or doesn't want to explain and defend the steps (or absense
>> of steps!) in terms of the end goal is out. I am not a child, and
>> neither are my students.
>
> I don't think any one was suggesting that and I think it stresses my
> earlier point - hire a coach.
Sorry, I won't. IMO an intellectual process that can't be explained in a
book, talk or article is not worth considering.
>
>> Richard, the same UART case for you: I must write a UART baudrate
>> initialization. The method accepts a run-time specified baudrate. Strict
>> 3-rule TDD keeps me in the cycle
>>
>> - write test case (for a specific baudrate)
>> - adapt code to pass that case
>>
>> This leads to code that has a list of if's or equivalent. It passes all
>> the tests, but it is crappy code. Now Ian says: refactor! You seem to
>> say: no, don't do that. So how does your process lead me to good code?
>
> I say refactor after each commit and I would be most surprised if
> Richard disagreed.
To quote Richard: "Instead of generalizing, I'm going to say that for
I would learn anything (except how to write bad code) when refactoring
is not allowed.
Wouter van Ooijen
doing something wrong writing (my own) software will not kill me. If I
get killed in the simulated fligts I will reconsider my opinion of the
sections I disregarded.
>> That is OK for muscle work (wax on, wax off), or for
>> accosciative creativity (which is almost muscle work), but not for
>> thinking processes. For me, any method that, while in the learning
>> phase, can't or doesn't want to explain and defend the steps (or absense
>> of steps!) in terms of the end goal is out. I am not a child, and
>> neither are my students.
>
> I don't think any one was suggesting that and I think it stresses my
> earlier point - hire a coach.
book, talk or article is not worth considering.
>
>> Richard, the same UART case for you: I must write a UART baudrate
>> initialization. The method accepts a run-time specified baudrate. Strict
>> 3-rule TDD keeps me in the cycle
>>
>> - write test case (for a specific baudrate)
>> - adapt code to pass that case
>>
>> This leads to code that has a list of if's or equivalent. It passes all
>> the tests, but it is crappy code. Now Ian says: refactor! You seem to
>> say: no, don't do that. So how does your process lead me to good code?
>
> I say refactor after each commit and I would be most surprised if
> Richard disagreed.
Uncle Bob's rules of TDD you should *literally* do them when learning TDD."
Maybe the difference is in "when learning", but that leads me to ask how
I would learn anything (except how to write bad code) when refactoring
is not allowed.
Wouter van Ooijen
Öö Tiib
Feb 20, 2016, 7:25:22 AM2/20/16
to
On Saturday, 20 February 2016 10:53:09 UTC+2, Wouter van Ooijen wrote:
> Op 20-Feb-16 om 9:17 AM schreef Ian Collins:
> > Wouter van Ooijen wrote:
> >> That is OK for muscle work (wax on, wax off), or for
> >> accosciative creativity (which is almost muscle work), but not for
> >> thinking processes. For me, any method that, while in the learning
> >> phase, can't or doesn't want to explain and defend the steps (or absense
> >> of steps!) in terms of the end goal is out. I am not a child, and
> >> neither are my students.
> >
> > I don't think any one was suggesting that and I think it stresses my
> > earlier point - hire a coach.
>
> Sorry, I won't. IMO an intellectual process that can't be explained in a
> book, talk or article is not worth considering.
I am also unsure about Uncle Bob so I ordered "Clean Code: A Handbook of
> Op 20-Feb-16 om 9:17 AM schreef Ian Collins:
> > Wouter van Ooijen wrote:
> >> That is OK for muscle work (wax on, wax off), or for
> >> accosciative creativity (which is almost muscle work), but not for
> >> thinking processes. For me, any method that, while in the learning
> >> phase, can't or doesn't want to explain and defend the steps (or absense
> >> of steps!) in terms of the end goal is out. I am not a child, and
> >> neither are my students.
> >
> > I don't think any one was suggesting that and I think it stresses my
> > earlier point - hire a coach.
>
> Sorry, I won't. IMO an intellectual process that can't be explained in a
> book, talk or article is not worth considering.
Agile Software Craftsmanship" of his. He is likely worth reading even
if I disagree with him.
>
> >
> >> Richard, the same UART case for you: I must write a UART baudrate
> >> initialization. The method accepts a run-time specified baudrate. Strict
> >> 3-rule TDD keeps me in the cycle
> >>
> >> - write test case (for a specific baudrate)
> >> - adapt code to pass that case
> >>
> >> This leads to code that has a list of if's or equivalent. It passes all
> >> the tests, but it is crappy code. Now Ian says: refactor! You seem to
> >> say: no, don't do that. So how does your process lead me to good code?
> >
> > I say refactor after each commit and I would be most surprised if
> > Richard disagreed.
>
> To quote Richard: "Instead of generalizing, I'm going to say that for
> Uncle Bob's rules of TDD you should *literally* do them when learning TDD."
>
> Maybe the difference is in "when learning", but that leads me to ask how
> I would learn anything (except how to write bad code) when refactoring
> is not allowed.
Refactoring during maintenance does result with major regressions without
unit tests. It likely is some misunderstanding here since Uncle Bob does
do it like all do (https://www.youtube.com/watch?v=y4_SJzNJnXU) and
from video it is hopefully clear how unit tests help there.
It is perhaps unfortunate that his TDD rules forget to mention it.
Wouter van Ooijen
Feb 20, 2016, 8:08:35 AM2/20/16
to
Op 20-Feb-16 om 1:24 PM schreef Öö Tiib:
dogmatic for my tase, and his favorite talking style is 'proof by
indoctrination'. I'll stick to Kent Beck, who seems (from a few
youtubes) to be much more pragmatic and to prefer giving arguments.
>
>>
>>>
>>>> Richard, the same UART case for you: I must write a UART baudrate
>>>> initialization. The method accepts a run-time specified baudrate. Strict
>>>> 3-rule TDD keeps me in the cycle
>>>>
>>>> - write test case (for a specific baudrate)
>>>> - adapt code to pass that case
>>>>
>>>> This leads to code that has a list of if's or equivalent. It passes all
>>>> the tests, but it is crappy code. Now Ian says: refactor! You seem to
>>>> say: no, don't do that. So how does your process lead me to good code?
>>>
>>> I say refactor after each commit and I would be most surprised if
>>> Richard disagreed.
>>
>> To quote Richard: "Instead of generalizing, I'm going to say that for
>> Uncle Bob's rules of TDD you should *literally* do them when learning TDD."
>>
>> Maybe the difference is in "when learning", but that leads me to ask how
>> I would learn anything (except how to write bad code) when refactoring
>> is not allowed.
>
> For me one major point pro unit testing (when I started) was refactoring.
> Refactoring during maintenance does result with major regressions without
> unit tests. It likely is some misunderstanding here since Uncle Bob does
> do it like all do (https://www.youtube.com/watch?v=y4_SJzNJnXU) and
> from video it is hopefully clear how unit tests help there.
> It is perhaps unfortunate that his TDD rules forget to mention it.
That is why I am pressing along about what the prponents really mean by
TDD. If it is the three rules and just those I think it is stupid, if it
includes refractoring it is surely worth considering.
It is of course totally obvious that having set of (regression) tests
that is cheap to run is almost a prerequisite to refactoring. But that
doesn't automatically require TDD.
Wouter van Ooijen
> On Saturday, 20 February 2016 10:53:09 UTC+2, Wouter van Ooijen wrote:
>> Op 20-Feb-16 om 9:17 AM schreef Ian Collins:
>>> Wouter van Ooijen wrote:
>>>> That is OK for muscle work (wax on, wax off), or for
>>>> accosciative creativity (which is almost muscle work), but not for
>>>> thinking processes. For me, any method that, while in the learning
>>>> phase, can't or doesn't want to explain and defend the steps (or absense
>>>> of steps!) in terms of the end goal is out. I am not a child, and
>>>> neither are my students.
>>>
>>> I don't think any one was suggesting that and I think it stresses my
>>> earlier point - hire a coach.
>>
>> Sorry, I won't. IMO an intellectual process that can't be explained in a
>> book, talk or article is not worth considering.
>
> I am also unsure about Uncle Bob so I ordered "Clean Code: A Handbook of
> Agile Software Craftsmanship" of his. He is likely worth reading even
> if I disagree with him.
From the tone of his talk I would not consider him worth reading, too
>> Op 20-Feb-16 om 9:17 AM schreef Ian Collins:
>>> Wouter van Ooijen wrote:
>>>> That is OK for muscle work (wax on, wax off), or for
>>>> accosciative creativity (which is almost muscle work), but not for
>>>> thinking processes. For me, any method that, while in the learning
>>>> phase, can't or doesn't want to explain and defend the steps (or absense
>>>> of steps!) in terms of the end goal is out. I am not a child, and
>>>> neither are my students.
>>>
>>> I don't think any one was suggesting that and I think it stresses my
>>> earlier point - hire a coach.
>>
>> Sorry, I won't. IMO an intellectual process that can't be explained in a
>> book, talk or article is not worth considering.
>
> I am also unsure about Uncle Bob so I ordered "Clean Code: A Handbook of
> Agile Software Craftsmanship" of his. He is likely worth reading even
> if I disagree with him.
dogmatic for my tase, and his favorite talking style is 'proof by
indoctrination'. I'll stick to Kent Beck, who seems (from a few
youtubes) to be much more pragmatic and to prefer giving arguments.
>
>>
>>>
>>>> Richard, the same UART case for you: I must write a UART baudrate
>>>> initialization. The method accepts a run-time specified baudrate. Strict
>>>> 3-rule TDD keeps me in the cycle
>>>>
>>>> - write test case (for a specific baudrate)
>>>> - adapt code to pass that case
>>>>
>>>> This leads to code that has a list of if's or equivalent. It passes all
>>>> the tests, but it is crappy code. Now Ian says: refactor! You seem to
>>>> say: no, don't do that. So how does your process lead me to good code?
>>>
>>> I say refactor after each commit and I would be most surprised if
>>> Richard disagreed.
>>
>> To quote Richard: "Instead of generalizing, I'm going to say that for
>> Uncle Bob's rules of TDD you should *literally* do them when learning TDD."
>>
>> Maybe the difference is in "when learning", but that leads me to ask how
>> I would learn anything (except how to write bad code) when refactoring
>> is not allowed.
>
> For me one major point pro unit testing (when I started) was refactoring.
> Refactoring during maintenance does result with major regressions without
> unit tests. It likely is some misunderstanding here since Uncle Bob does
> do it like all do (https://www.youtube.com/watch?v=y4_SJzNJnXU) and
> from video it is hopefully clear how unit tests help there.
> It is perhaps unfortunate that his TDD rules forget to mention it.
TDD. If it is the three rules and just those I think it is stupid, if it
includes refractoring it is surely worth considering.
It is of course totally obvious that having set of (regression) tests
that is cheap to run is almost a prerequisite to refactoring. But that
doesn't automatically require TDD.
Wouter van Ooijen
Richard
Feb 20, 2016, 8:20:00 PM2/20/16
to
[Please do not mail me a copy of your followup]
Wouter van Ooijen <wou...@voti.nl> spake the secret code
<56c81ec1$0$4200$e4fe...@newszilla.xs4all.nl> thusly:
>But, as I understand (both of you, correct me if I am wrong) the rules
>that Richard wants to be followed strictly *exclude* refactoring, while
>Ians rules *include* it. For me that's the difference between night and day.
Uncle Bob's rules prevent you from writing anything more than the
minimal code necessary to pass the test. Minimal means you can't
extract new functions/methods to eliminate the duplication until the
tests are passing. That's why the refactoring stage is essential.
The refactoring stage is also essential in making design an activity
that you do every few minutes all day long instead of a phase that you
do before you implement. The only way to become a good designer of
code structures is to practice. The best way to practice designing is
to do it all the time and TDD does that in quick cycles with feedback.
Richard
Feb 20, 2016, 8:22:03 PM2/20/16
to
[Please do not mail me a copy of your followup]
Wouter van Ooijen <wou...@voti.nl> spake the secret code
<56c81ec1$0$4200$e4fe...@newszilla.xs4all.nl> thusly:
<56c81ec1$0$4200$e4fe...@newszilla.xs4all.nl> thusly:
>But, as I understand (both of you, correct me if I am wrong) the rules
>that Richard wants to be followed strictly *exclude* refactoring, while
>Ians rules *include* it.
I've given a workshop at C++ Now 2014 on TDD in C++. You should look at
>that Richard wants to be followed strictly *exclude* refactoring, while
>Ians rules *include* it.
the slides and associated code to understand how I present TDD:
<https://github.com/boostcon/cppnow_presentations_2014/tree/master/files/test_driven>
Wouter van Ooijen
Feb 21, 2016, 3:29:48 AM2/21/16
to
Op 21-Feb-16 om 2:19 AM schreef Richard:
But that doesn't seem to be this page
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd , or did I
somehow misread that page?
Wouter van Ooijen
> [Please do not mail me a copy of your followup]
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <56c81ec1$0$4200$e4fe...@newszilla.xs4all.nl> thusly:
>
>> But, as I understand (both of you, correct me if I am wrong) the rules
>> that Richard wants to be followed strictly *exclude* refactoring, while
>> Ians rules *include* it. For me that's the difference between night and day.
>
> The cycle is red, green, refactor. The refactor step is essential.
Ah, we are all on the same page now.
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <56c81ec1$0$4200$e4fe...@newszilla.xs4all.nl> thusly:
>
>> But, as I understand (both of you, correct me if I am wrong) the rules
>> that Richard wants to be followed strictly *exclude* refactoring, while
>> Ians rules *include* it. For me that's the difference between night and day.
>
> The cycle is red, green, refactor. The refactor step is essential.
But that doesn't seem to be this page
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd , or did I
somehow misread that page?
Wouter van Ooijen
Paul Sinnett
Feb 21, 2016, 11:08:42 AM2/21/16
to
> Ah, we are all on the same page now.
>
> But that doesn't seem to be this page
> http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd , or did I
> somehow misread that page?
>
> Wouter van Ooijen
Try this one, it's newer, but also by Bob and explicitly includes the red/green/refactor cycle: http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
>
> But that doesn't seem to be this page
> http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd , or did I
> somehow misread that page?
>
> Wouter van Ooijen
Richard
Feb 22, 2016, 12:07:21 AM2/22/16
to
[Please do not mail me a copy of your followup]
Wouter van Ooijen <wou...@voti.nl> spake the secret code
<56c97575$0$4316$e4fe...@newszilla.xs4all.nl> thusly:
Wouter van Ooijen <wou...@voti.nl> spake the secret code
mention refactoring on there. My guess is that he's focused on when
and how you can introduce new functionality under strict TDD rules
because this is the part that most people get wrong when they try TDD.
Mr Flibble
Feb 22, 2016, 2:44:03 PM2/22/16
to
On 22/02/2016 05:07, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <56c97575$0$4316$e4fe...@newszilla.xs4all.nl> thusly:
>
>> Op 21-Feb-16 om 2:19 AM schreef Richard:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Wouter van Ooijen <wou...@voti.nl> spake the secret code
>>> <56c81ec1$0$4200$e4fe...@newszilla.xs4all.nl> thusly:
>>>
>>>> But, as I understand (both of you, correct me if I am wrong) the rules
>>>> that Richard wants to be followed strictly *exclude* refactoring, while
>>>> Ians rules *include* it. For me that's the difference between night and day.
>>>
>>> The cycle is red, green, refactor. The refactor step is essential.
>>
>> Ah, we are all on the same page now.
>>
>> But that doesn't seem to be this page
>> http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd , or did I
>> somehow misread that page?
>
> I looked at that page after your post. I don't know why he doesn't
> mention refactoring on there. My guess is that he's focused on when
> and how you can introduce new functionality under strict TDD rules
> because this is the part that most people get wrong when they try TDD.
TDD and classic refactoring are in conflict. TDD is bollocks pure and
> [Please do not mail me a copy of your followup]
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <56c97575$0$4316$e4fe...@newszilla.xs4all.nl> thusly:
>
>> Op 21-Feb-16 om 2:19 AM schreef Richard:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Wouter van Ooijen <wou...@voti.nl> spake the secret code
>>> <56c81ec1$0$4200$e4fe...@newszilla.xs4all.nl> thusly:
>>>
>>>> But, as I understand (both of you, correct me if I am wrong) the rules
>>>> that Richard wants to be followed strictly *exclude* refactoring, while
>>>> Ians rules *include* it. For me that's the difference between night and day.
>>>
>>> The cycle is red, green, refactor. The refactor step is essential.
>>
>> Ah, we are all on the same page now.
>>
>> But that doesn't seem to be this page
>> http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd , or did I
>> somehow misread that page?
>
> I looked at that page after your post. I don't know why he doesn't
> mention refactoring on there. My guess is that he's focused on when
> and how you can introduce new functionality under strict TDD rules
> because this is the part that most people get wrong when they try TDD.
simple.
/Flibble
Ian Collins
Feb 22, 2016, 2:58:50 PM2/22/16
to
Mr Flibble wrote:
>
> TDD and classic refactoring are in conflict. TDD is bollocks pure and
> simple.
How is your considered critique coming along?
>
> TDD and classic refactoring are in conflict. TDD is bollocks pure and
> simple.
--
Ian Collins
Mr Flibble
Feb 22, 2016, 3:13:07 PM2/22/16
to
Griffin's voice.
/Flibble
Wouter van Ooijen
Feb 22, 2016, 3:19:26 PM2/22/16
to
Op 22-Feb-16 om 8:44 PM schreef Mr Flibble:
Explaining the conflict would be more usefull than just asserting that
there is a conflict.
And why the 'classic'? You see to imply that TDD is not in conflict with
some other type of refactoring?
> TDD is bollocks pure and simple.
Again, providing details is more usefull than a simple assertion. And as
a lengthy discussion has shown me, it is usefull to state what you think
TDD is exactly. I would agree with you when TDD == (the three rules
without refactoring), but that seems to be a strawman.
Wouter van Ooijen
there is a conflict.
And why the 'classic'? You see to imply that TDD is not in conflict with
some other type of refactoring?
> TDD is bollocks pure and simple.
a lengthy discussion has shown me, it is usefull to state what you think
TDD is exactly. I would agree with you when TDD == (the three rules
without refactoring), but that seems to be a strawman.
Wouter van Ooijen
Ian Collins
Feb 22, 2016, 3:20:09 PM2/22/16
to
--
Ian Collins
Mr Flibble
Feb 22, 2016, 3:21:42 PM2/22/16
to
On 22/02/2016 20:19, Ian Collins wrote:
> Mr Flibble wrote:
>> On 22/02/2016 19:58, Ian Collins wrote:
>>> Mr Flibble wrote:
>>>>
>>>> TDD and classic refactoring are in conflict. TDD is bollocks pure and
>>>> simple.
>>>
>>> How is your considered critique coming along?
>>
>> I do hope you are writing that whilst saying it out loud in Stewie
>> Griffin's voice.
>
> Who?
https://www.youtube.com/watch?v=NTSGp4UdEvQ
> Mr Flibble wrote:
>> On 22/02/2016 19:58, Ian Collins wrote:
>>> Mr Flibble wrote:
>>>>
>>>> TDD and classic refactoring are in conflict. TDD is bollocks pure and
>>>> simple.
>>>
>>> How is your considered critique coming along?
>>
>> I do hope you are writing that whilst saying it out loud in Stewie
>> Griffin's voice.
>
> Who?
/Flibble
Juha Nieminen
Feb 23, 2016, 4:14:33 AM2/23/16
to
>> TDD and classic refactoring are in conflict.
>
> Explaining the conflict would be more usefull than just asserting that
> there is a conflict.
I can't even begin to imagine how there is a conflict. Seems pretty
>
> Explaining the conflict would be more usefull than just asserting that
> there is a conflict.
straightforward to me: If you need to change something in the code
(from TDD's point of view usually something that affects a public
interface), you first change the test, then you change the code.
I honestly cannot see what the "conflict" is...
Refactoring that's internal to a class/module (ie. does not affect
external behavior) often doesn't even need changing the tests.
Especially in the latter case it sounds more to me that TDD aids
in refactoring because you immediately have a basic set of tests
to make sure that your changes didn't break anything. (Sure, TDD
doesn't test it 100%, but even the basic tests help quite a lot.)
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Ian Collins
Feb 23, 2016, 4:21:50 AM2/23/16
to
conjures up his nonsense, some odd fortune cookies maybe?
--
Ian Collins
Mr Flibble
Feb 23, 2016, 12:33:38 PM2/23/16
to
does it hinder designing things properly it also prevents you
refactoring a design to make it even better. TDD is considered harmful.
/Flibble
Wouter van Ooijen
Feb 23, 2016, 1:28:50 PM2/23/16
to
Op 23-Feb-16 om 6:33 PM schreef Mr Flibble:
You might be right, but you will only be listened to when you explain.
> it also prevents you
> refactoring a design to make it even better.
Again, explain how.
> TDD is considered harmful.
If that is true, only the force of your *arguments* will stop it.
So far, a few TDD proponents gave me arguments (in favour, of course).
As yet, you gave none. Do you want me (and other readers) to make up my
mind just based on the arguments of the proponents? (That would put you
on their side!)
Wouter
> it also prevents you
> refactoring a design to make it even better.
> TDD is considered harmful.
If that is true, only the force of your *arguments* will stop it.
So far, a few TDD proponents gave me arguments (in favour, of course).
As yet, you gave none. Do you want me (and other readers) to make up my
mind just based on the arguments of the proponents? (That would put you
on their side!)
Wouter
Ian Collins
Feb 23, 2016, 2:44:05 PM2/23/16
to
Mr Flibble wrote:
> On 23/02/2016 09:21, Ian Collins wrote:
>> Juha Nieminen wrote:
>>> Wouter van Ooijen <wou...@voti.nl> wrote:
>>>> Op 22-Feb-16 om 8:44 PM schreef Mr Flibble:
>>>>> TDD and classic refactoring are in conflict.
>>>>
>>>> Explaining the conflict would be more usefull than just asserting that
>>>> there is a conflict.
>>>
>>> I can't even begin to imagine how there is a conflict. Seems pretty
>>> straightforward to me: If you need to change something in the code
>>> (from TDD's point of view usually something that affects a public
>>> interface), you first change the test, then you change the code.
>>> I honestly cannot see what the "conflict" is...
>>>
>>> Refactoring that's internal to a class/module (ie. does not affect
>>> external behavior) often doesn't even need changing the tests.
>>>
>>> Especially in the latter case it sounds more to me that TDD aids
>>> in refactoring because you immediately have a basic set of tests
>>> to make sure that your changes didn't break anything. (Sure, TDD
>>> doesn't test it 100%, but even the basic tests help quite a lot.)
>>
>> It certainly does aid in refactoring. I don't know from where he
>> conjures up his nonsense, some odd fortune cookies maybe?
>
> Nonsense?
Yes nonsense.
> On 23/02/2016 09:21, Ian Collins wrote:
>> Juha Nieminen wrote:
>>> Wouter van Ooijen <wou...@voti.nl> wrote:
>>>> Op 22-Feb-16 om 8:44 PM schreef Mr Flibble:
>>>>> TDD and classic refactoring are in conflict.
>>>>
>>>> Explaining the conflict would be more usefull than just asserting that
>>>> there is a conflict.
>>>
>>> I can't even begin to imagine how there is a conflict. Seems pretty
>>> straightforward to me: If you need to change something in the code
>>> (from TDD's point of view usually something that affects a public
>>> interface), you first change the test, then you change the code.
>>> I honestly cannot see what the "conflict" is...
>>>
>>> Refactoring that's internal to a class/module (ie. does not affect
>>> external behavior) often doesn't even need changing the tests.
>>>
>>> Especially in the latter case it sounds more to me that TDD aids
>>> in refactoring because you immediately have a basic set of tests
>>> to make sure that your changes didn't break anything. (Sure, TDD
>>> doesn't test it 100%, but even the basic tests help quite a lot.)
>>
>> It certainly does aid in refactoring. I don't know from where he
>> conjures up his nonsense, some odd fortune cookies maybe?
>
> Nonsense?
> It is self evident that it is TDD that is nonsense; not only
> does it hinder designing things properly it also prevents you
> refactoring a design to make it even better.
incorporates refactoring prevent it?
I assume you don't post any evidence because you don't have any and
can't provide a coherent analysis of your own. So you just keep
repeating "the sky is green" hoping it is. Repetition isn't argument.
> TDD is considered harmful.
By whom? References please.
--
Ian Collins
Mr Flibble
Feb 23, 2016, 3:13:56 PM2/23/16
to
time you have invested into TDD and your unwillingness to lose face if
you back out of it now. You have to justify the contents of your CV
right? I am sorry you have put so much effort into TDD mate but you
have been and still are doing it wrong.
Unit testing is great; TDD isn't. TDD is considered harmful.
/Flibble
Gareth Owen
Feb 23, 2016, 3:53:26 PM2/23/16
to
Mr Flibble <flibbleREM...@i42.co.uk> writes:
> The fundamental problem here is your sense of dread at the amount of
> time you have invested into TDD and your unwillingness to lose face if
> you back out of it now
I believe this is known as "projection"
> The fundamental problem here is your sense of dread at the amount of
> time you have invested into TDD and your unwillingness to lose face if
> you back out of it now
Ian Collins
Feb 23, 2016, 3:54:06 PM2/23/16
to
Mr Flibble wrote:
>
> The fundamental problem here is your sense of dread at the amount of
> time you have invested into TDD and your unwillingness to lose face if
> you back out of it now.
No, the fundamental problem here is you keep repeating the same bollocks
>
> The fundamental problem here is your sense of dread at the amount of
> time you have invested into TDD and your unwillingness to lose face if
> you back out of it now.
without any evidence to back it up. Present some or admit you don't
have any.
> You have to justify the contents of your CV
> right?
> Unit testing is great; TDD isn't. TDD is considered harmful.
--
Ian Collins
Gareth Owen
Feb 23, 2016, 4:09:18 PM2/23/16
to
Ian Collins <ian-...@hotmail.com> writes:
> The sky is green.
I think you'll find the sky is *considered* green.
> The sky is green.
I think you'll find the sky is *considered* green.
David Brown
Feb 23, 2016, 4:22:38 PM2/23/16
to
colour, because they didn't have a word for "blue". Maybe Mr. Flibble
considers TDD to be harmful because he doesn't have a word for "useful".
* According to the infallible QI elves. What more evidence could one
ask for?
Richard
Feb 24, 2016, 12:12:55 PM2/24/16
to
[Please do not mail me a copy of your followup]
Gareth Owen <gwo...@gmail.com> spake the secret code
<87a8mrg...@gmail.com> thusly:
I have been programming for a really long time (decades) and been doing
TDD since roughly 2007. During that time I have always sought to learn
new ways of programming to improve my productivity and/or the quality
of the code I produce. I value quality, so I am willing to sacrifice
some productivity in order to obtain better quality. TDD was the
first thing that felt like I didn't have to give up productivity in
order to obtain quality, provided we look at the total time spent
developing a feature and not just the time it took to type in the
code and make it compile.
In practical terms, this means that I am willing to write automated tests
around my code in order to prove that my code works now and continues
to work properly in the future. Clearly that could be a net productivity
loss in the short-term because I spent the time to write the automated
tests. When you're the first person on the team to write some
automated tests, you also have to introduce the infrastructure to
support such tests into the code base.
I say short-term productivity cost because the time spent writing tests
and finding stupid mistakes early is offset by time spent later in the
debugger finding the cause of strange bugs reported by other developers
on my team, the testing team or customers. I am very proficient in a
debugger so most of the time I am able to quickly identify the root
cause of a bug with the debugger. However, I find the same stupid
mistakes more efficiently when I write automated tests around my code.
I haven't really noticed a significant decline in my error rate over
time, but the tools I use are more adept at finding my mistakes so the
total time between creation, discovery and correction of mistakes has
been made shorter over time. TDD doesn't reduce my error rate but it
does reduce the total time spent identifying and correcting errors.
In earlier posts I have described the benefit of changing design from
a phase to a daily activity that I have found when practicing TDD.
As a result I get better designs from my code and the code I produce
is consistent with the advice from leaders in the field of
programming, both specific to C++ and more generally.
The design benefits and the quality benefits are why TDD works for me.
If you are more productive doing something else, then great for you.
My case for TDD is purely based on the pragmatic benefits I've seen
in my personal experience. That personal experience is echoed across
enough developers that it's not just a fluke that happens to work for me.
The experience is pretty consistent across languages and personality types
and so-on and this is why Uncle Bob says it is simply unprofessional if
you don't do something like TDD when you write code for a living. He
is intentionally making a provocative statement when he says that. He
is also making the argument from a pragmatic perspective; he does not
say TDD is a silver bullet, he says it is the best thing he has found
so far. If you have something better, please show it to him.
Am I ideologically invested in TDD? No.
Am I pragmatically invested in TDD? Yes.
Show me something better and I'll do that. Simply saying TDD sucks or
whatever isn't enough to convince me to give up the pragmatic benefits
that I have found by practicing TDD. Particularly when the thing I'm
being told to do is the thing I was already doing proficiently for decades
before I came to practice TDD. In essence, the argument is regressive
and telling me to give up the benefits I've gained from TDD.
Mr Flibble
Feb 24, 2016, 1:06:08 PM2/24/16
to
On 24/02/2016 17:12, Richard wrote:
> In earlier posts I have described the benefit of changing design from
> a phase to a daily activity that I have found when practicing TDD.
> As a result I get better designs from my code and the code I produce
> is consistent with the advice from leaders in the field of
> programming, both specific to C++ and more generally.
I doubt that very much. Designing software by fixing failing tests is
> In earlier posts I have described the benefit of changing design from
> a phase to a daily activity that I have found when practicing TDD.
> As a result I get better designs from my code and the code I produce
> is consistent with the advice from leaders in the field of
> programming, both specific to C++ and more generally.
not software design at all and for this reason I suspect the quality of
your TDD driven designs is very poor.
*Good* software design is:
1) Thinking about system architecture;
2) Based on 1) designing the software architecture;
3) Thinking about abstractions;
4) Based on 2) and 3) designing interfaces;
5) Based on 3) and 4) designing class hierarchies and concrete classes;
6) Designing object hierarchies, and object lifetime envelopes.
*Good* software design is not:
1) Make a failing test pass.
Obviously requirements gathering and analysis is a given.
/Flibble
0 new messages