212: Canon TDD - by Kent Beck

In 2002, Kent Beck released a book called  "Test Driven Development by Example".
In December of 2023, Kent wrote an article called "Canon TDD".
With Kent's permission, this episode contains the full content of the article.

Brian's commentary is saved for a followup episode.

Links:

• Canon TDD
• Test Driven Development by Example

Episode Transcript

Brian (00:00):
The late 1990s , Extreme Programming brought us a concept
called "Test First Programming".In 2002, Kent Beck released a
book called "Test DrivenDevelopment by Example". In
December of 2023, Kent wrote anarticle called "Canon TDD". With
Kent's permission, I am going toread that article in this

(00:22):
episode. I'm gonna save mycommentary for a follow-up
episode.
Now here's Canon TDD by KentBeck.

(01:19):
Number 1. Write a list of testscenarios you wanna cover.
Number 2. Turn exactly one itemon the list into an actual
concrete runnable test.
Number 3. Change the code tomake the test and all previous
tests pass, adding items to thelist as you discover them.
Number 4, optionally refactor toimprove the implementation

(01:39):
design.
Number 5, Until the list isempty, go back to number 2. In
my recent round of test roomdevelopment clarifications, one
surprising experience is
that folks out there don't agreeon the definition of TDD.
I made it as clear as possiblein my book. I thought it was
clear. Nope. My bad. If you'redoing something different than

(02:00):
the following workflow and itworks for you, congratulations.
It's not Canon TDD, but whocares? There's no gold star for
following these steps exactly.If you plan on critiquing TDD
and you're not critiquing thefollowing workflow, then you're
critiquing a straw man. That'smy point in spending some of the
precious remaining seconds of mylife writing this for stalling

(02:22):
straw man. I'm not telling youhow to program.
I'm not charging for gold stars.I try to be positive and
constructive as a habit. Bynecessity, this post is going to
be concise and negative. Peopleget this wrong. Here's the
actual thing.
I don't mean to critiquesomeone's workflow, but sharpen
their understanding of CanonTDD. Overview. Test driven

(02:45):
development is a programmingworkflow. A programmer needs to
change the behavior of a system,which may be empty just now. TDD
is intended to help theprogrammer create a new state of
the system where everything thatused to work still works.
The new behavior works asexpected. The system is ready
for the next change. Theprogrammer and their colleagues

(03:05):
feel confident in the the abovepoints. Interface implementation
split. The firstmisunderstanding is that folks
seem to lump all designtogether.
There are 2 flavors, how aparticular piece of behavior is
invoked, how the systemimplements that behavior. When I
was in school, we called theselogical and physical design and
were told never to mix the 2,but nobody ever explained how. I

(03:28):
had to figure that out later.The steps. People are lousy
computers.
What follows looks like acomputer program, but it's not.
It's written this way to attemptto communicate effectively with
people who are used to workingwith programs. I say attempt
because as noted, folks seemprone to saying, TDD sucks dude.

(03:49):
I did something else entirelyand it failed. Number 1, test
list.
The initial step in TDD given asystem and desired change in
behavior is to list all theexpected variance in the new
behavior. There's the basic caseand then if this service times
out and what if the key isn't inthe database yet and etcetera?

(04:10):
This is analysis, but behavioralanalysis. You're thinking of all
the different cases in which abehavior change should work. If
you think of ways the behaviorchange shouldn't break existing
behavior, throw that in theretoo.
Mistake. Mixing inimplementation designs
decisions. Chill. There will beplenty of time to decide how the

(04:30):
internals will look later.You'll do a better job of
listing tests if that's all youconcentrate on.
If you need an implementationsketch in Sharpie on a napkin,
go ahead, but you might notreally need it. Experiment.
Folks seem to have missed thisstep in the book. TDD just
launches into coding. You neverknow when you're done.
Nope. Number 2, write a test.One test, a really truly

(04:54):
automated test with setup andinvocation and assertions. Pro
tip. Trying working backwardsfrom the assertions sometime.
It's in the writing of this testthat you'll begin making design
decisions, but they areprimarily interface decisions.
Some implementation decisionsmay leak through, but you'll get
better at avoiding this overtime. Mistake. Writing tests

(05:16):
without assertions just to getcode coverage. Mistake.
Convert all the items on thetest list into concrete tests,
then make them pass 1 at a time.What happens when making the
first test pass causes you toreconsider a decision that
affects all of those speculativetests? Rework. What happens when
you get to test number 6 and youhaven't seen anything pass yet?

(05:37):
Depression and or boredom.
Picking the next test is animportant skill and one that
only comes with experience. Theorder of the test can
significantly infect both theexperience of programming and
the final result. Open question,is code sensitive to initial
conditions? Number 3. Make itpass.
Now that you have a failingtest, change the system so the

(05:59):
test passes. Mistake. Deleteassertions so the test pretends
to pass. No. Make it pass forreal.
Mistake. Copying actual computedvalues and pasting them into the
expected values of the test.That defeats double checking,
which creates much of thevalidation value of TDD.
Mistake. Mixing refactoring intomaking the test pass, again,

(06:20):
with the wearing 2 hats problem,make it run, then make it right.
Your brain will eventually thankyou. If in the process of going
red to green, you discover youneed a new test added to the
test list. If the testinvalidates the work you've done
already, oh, no, There's no wayto handle the case of an empty
folder. You need to decidewhether to push on or start

(06:41):
over. Pro tip, start over butpick a different order to
implement the tests.
When the test passes, mark itoff the list. Number 4,
optionally refactor. Now you getto make implementation design
decisions. Mistake, Refactoringfurther than necessary for this
session. It feels good to tidystuff up.
It can feel scary to face thenext test, especially if it's

(07:01):
one you don't know how to get topass. I'm stuck on this on a
side project right now. Mistake.Abstracting too soon.
Duplication is a hint, not acommand.
Number 5. Until the list isempty, go to 2. Keep testing and
coding until your fear for thebehavior of the code has been
transmuted into boredom.
A link to this article by Kentwill be included in the show

(07:24):
notes.