NW story: Can’t do TDD, they haven’t even figured out unit tests yet!
TDD is easier.My personal goal is to show you Robbie’s point of view. Perhaps you’ll make it your own.
Codified by Kent Beck.From his XP practices.Led to automated unit-test frameworks and refactoring tools.Adapted by Agilists into two distinct practices.
Problem:Time spent RE-testingTime spent debugging
SolutionFastRepeatable resultsBetter than…
Story 15 years old, at least (Phoenix).Truck stuck.Fire dept and others arrive and try to figure out what to do.Anecdotally, a young man walks up and says “Why not deflate the tires?”Developers can think about a problem and come up with a possible solution.BUT…first specify the question (Jeopardy-style)
We’re talking about a single coding event (story?) and it’s test. If the coding cycle is months, then the delay could be months.The developer will have forgotten. The BA/PO may have forgotten, too!<done with anim and closing gap> Where do we gain value from testing? Running the test, or writing it?
If you have to think about how you’d interact with the product, what are you doing? [Analysis]This is the final detailed analysis of a story before AND WHILE it’s being implemented. JIT Analysis!
Reduces defects now: Tells you when a task is done, and done correctly.Reduces defects later: Comprehensive suite of isolated regression tests detect and isolate failures immediately.Much less time troubleshooting/debugging and re-testing.For developersBugs are easier and faster to fix while they’re freshBugs are found and fixed before other dependent code is writtenFewer returns from QA, more time spent on developing not fixingFor TestersSpend more time on more critical testing (not finding and validating defects)For the Whole TeamDaily measurable progressProduct health and flexibilitySanity in the workplace and enjoyable work
Problem: Iterations imply incremental developmentChange can result in a negative feedback loop - ENTROPY: The Agilist’s DilemmaWe have to address this. It’s not easy, until it becomes easy. At first, we’d rather not check the oil…
One Analogy for the DesignThe suite of tests preserves all prior behavior while we address design, allowing for Emergent Designs
AnAnalogy for theProgrammer:Each test remains as an individual investment in the behavior and the quality of the design
Does TDD Work?Microsoft and IBM…Also, “approximately 40% fewer defects” Laurie Williams for ACMdefect rate is considerably lowerfuture enhancements easierin a dynamic market. defects quickly detected
Weinberg’s “Are Your Lights On?” Golden ______OTIS2 data conversionOTIS2 “GUI” conversionDenali Internationalization
Roadblocks to AdoptionDevelopers skip refactoring, don’t spend the minute to look for and clean up a new bit of code duplication.Inexperienced coaches who confuse the developer-style TDD with the team ATDDManagers waffling over the use of TDD, which limits its effectiveness…and others.
A habit…We still use when times are tough…Because we know there is a long-term benefit.Habit: 30-days, support-groupBenefits org, team, individualDiscipline prevents regret (debt).
We thought about “Deposit” except that’s not what it is once it’s been deposited<click>And we’re going to tackle Holding first
Holding has a useful interface so it may convert its value to different currency, but… the conversion doesn’t really belong in Holding, does it? My gut is telling me it will be helpful to isolate it, keep it simpleIf we guess wrong? Refactor away CurrencyConverter. RARE REFACTORING!
Read it<click>tolerance<click> won’t compile, of course
VS writes this. Nice, in case we ever forget, but I want the test to FAIL, not THROW.
Is this crazy?
If it’s a constant, make it a constantOr find a simplistic implementation
If there’s no clear refactoring, go on to the next test.
Rodin’s chipping away whatever didn’t look like a seated manTriangulation *IS* Test-First<click>Don’t add more production BEHAVIOR without a failing test.
This is a perfectly good design for what we’ve asked the system to do so far.As long as the design does not start to DEGRADE!
It’s not really about reduction of duplication, but about arranging for all tests in the class.One test class per behavior group.
What if we don’t know?Find out, or make it happen.
Why? To isolate the problem.Note that we’re thinking about parameter lists. “Programming by intention”. If we miss one, we can refactor further, later.
Should the converter know?
We’re deferring the decision.<TODO: Maybe draw a sequence diagram!>
Part of Emergent Design: Discovering that YOU need something, and building it.
Refactor? Is there duplication?
If you doubt yourself, just change one of the 50’s.Now there’s duplication in the test. Make a constant <TODO: do it!>
We’re not actually going to do it, but what might it look like?
We could do these.Or we could, as a team, test that they are impossible.What benefit in NOT doing these? [Simplicity, else each object has to be defensive, as though it were being exposed to “other programmers”]
Which I will leave for the enthusiastic TDD programmer to complete (it ain’t hard)