TDDbE: Introduction

The introduction is an interesting story of technical debt: the work on improving the internal quality of the code, and in particular the outsourced `Dollar` object, had been on-going for six months before the arrival of the business opportunity that needed the improved design.

(The debt metaphor first appears in Ward's 1992 experience report, which describes this same portfolio management system).

The transition from testing that computations are within tolerance to testing that computations are exact hides an important lesson: code changes that relocate rounding within a calculation are not refactorings in domains where the calculations are regulated, and you do want tests that are sensitive to those changes if refactoring is a core value.

In a broader sense, we're also getting a statement of good design; a design is good if it is ready to be changed.

I suspect that the story takes place circa 1992, so of course the team isn't doing "TDD", and there's no particular indication that the team is taking a test first approach.  The promise here is really that TDD can bring you to this place that the Wyatt team got to another way (not too different though -- "if you assume all the good ideas in here are Ward's" and all that).

We also get our first look at the two simple rules

• Write a failing automated test before you write any code.
  
• Remove duplication.
  

The first of these, I think, fails, in the sense that it describes an XP approach where you turn up the dials to eleven to see how it works.  And it works a lot, but it doesn't work eleven - the costs of writing automated tests are not uniform, and expensive tests against unstable specifications is generally a miserable experience for everybody.

In regarding the second rule, it's probably worth noting that, at the time, Kent had a reputation for being something of a wizard at recognizing duplication, and pursuing a sequence of refactorings that would eventually make the duplication obvious to everyone else, and finally taking steps to remove it.

I suspect that there is a similar skill, in which we take two things that look to be the same and improve the design until it becomes clear that they are not, in fact, duplicates.

Remove duplication hints at the four rules of simple design.  One of the questions I'm still carrying around is whether the rules of simple design are part of the TDD bundle -- are we still "doing TDD" if we replace simple design with some other collection of design heuristics?

TDDbE: Preface

Opening paragraph: the goal of Test Driven Development is "clean code that works" - which is a bit of sloganeering describing the stop condition.  TDD is a way to apply our effort to achieve the stop condition.

First promise: the long bug trail after "done" goes away.  Certainly a lot of the faults in complicated logic should have been identified and eliminated, because we will be making sure to design our systems so that testing the complicated logic is cost effective (i.e. relentlessly reducing the coupling between complicated logic and modules that are difficult or expensive to test).  Depending on how much of your system is complex logic, that could be the bulk of your problem right there.

It gives you a chance to learn all of the lessons that the code has to teach you.

This one, I'll need to chew on.  You've got structured time to focus attention, but there's an opportunity cost associated with each of these lessons.

• Write new code only if an automated test has failed
• Eliminate duplication

These are two simple rules....

Eliminate duplication being a rule is kind of important, in so far as it pulls one of the pillars of the four rules of simple design into a definition of TDD.  Sandro Mancuso has suggested that the four rules of simple design are separate from TDD, and while I'm receptive to the idea that they should be, the rule listed here means it isn't quite so easy.

A lot of lip service was paid to the "only if" rule early on.  Michael Feathers introduced Humble Dialog before TDDbE was published, and we already had people using test doubles as an isolation mechanism.  I think you can interpret that a lot of different ways - either the rule isn't so absolute, or the rule is absolute but the TDD process isn't sensible for all coding problems.

Running code providing feedback between decisions

This is a riddle I've been thinking on lately: the obvious feedback we get between decisions is red/green bar, announcing whether the values measured in our experiments match the described specifications.  But the feedback for the design decisions - running the code doesn't give us very much there.  Feedback for design decisions must come from somewhere else.

Refactor - Eliminate all of the duplication created in merely getting the test to work.

This is a big one: in my experience, most to nearly all practitioners move on from the refactor phase while duplication is still present.  Back in the day, Beck had a reputation for being something of a wizard in spotting duplication that wasn't obvious and immediately taking steps to eliminate it.

Next, lots of emphasis on implications of reduced defect density.  Just something to notice, possibly in contrast to his earlier writings about test first being primarily an analysis and design technique.

I'm noticing in passing that he isn't making any attempt here to clarify whether he is talking about reduced defect density because defects are being discovered and removed, or reduced defect density because fewer defects are being introduced.

TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap.

 One of my two favorite quotations from the book.

Some software engineers learn TDD and then revert to their earlier practices, reserving TDD for special occasions when ordinary programming isn't making progress.

Huh.  If this sentence is written in 2009 - fine, there's been lots of time for people to try it, learn it, and decide it's a sometimes useful tool in the kit.  On the other hand, if that sentence goes back to the earliest drafts, then it becomes a very interesting statement about some of the early adopters.

There certainly are programming tasks that can't be driven solely by tests.  Security software and concurrency, for example, are two topics where TDD is insufficient to mechanically demonstrate that the goals of the software have been met.

 Horses for courses.

Before teeing off on the examples as being too simple

Well, I certainly do do that often enough - mostly because the starting position (money as model code) already elides a bunch of interesting decisions about module boundaries.  And weren't we promising that the tests would "drive" those decisions?

 

Book Club: Test Driven Development by Example

I think I'll try a review of Test Driven Development by Example.  I'll be using the 14th printing (October 2009) paperback

• Preface
• Introduction
• Multi-Currency Money
• Degenerate Objects 
• Equality for All
• Privacy
• Franc-ly Speaking
• Equality for All, Redux
• Apples and Oranges
• Makin' Objects
• Interesting Times
• The Root of All Evil
• Addition, Finally
• Make It
• Change
• Mixed Currencies 
• Abstraction, Finally
• Money Retrospective
• First Steps to xUnit
• Set the Table
• Cleaning Up After
• Counting
• Dealing with Failure
• How Suite It Is
• xUnit Retrospective
• Test-Driven Development Patterns
• Red Bar Patterns
• Testing Patterns
• Green Bar Patterns
• xUnit Patterns
• Design Patterns
• Refactoring
• Mastering TDD 
  

Schools of Test Driven Development

There are two schools of test driven development.  There is the school that believes that there are two schools; and there is the school that believes that there is only one school.

The school of "only one school" is correct.

As far as I can tell, "Chicago School" is an innovation introduced by Jason Gorman in late 2010.  Possibly this is a nod to the fact that Object Mentor was based in Evanston, Illinois.

"Chicago School" appears to be synonymous with "Detroit School", a term proposed by Michael Feathers in early 2009.  Detroit, here, because the Chrysler Comprehensive Compensation team was based in Detroit; and the lineage of the "classical" TDD practices could be traced there.

Feathers brought with that proposal the original London School label, for practices more readily influenced by innovations at Connextra and London Extreme Tuesday Club.

Feathers was proposing the "school" labels, because he was at that time finding that the "Mockist"  and "Classicist" labels were not satisfactory.

The notion that we have two different schools of TDDer comes from Martin Fowler in 2005.

This is the point where things get muddled - to wit, was Fowler correct to describe these schools as doing TDD differently, or are they instead applying the same TDD practices to a different style of code design?

 Steve Freeman, writing in 2011, offered this observation

...There are some differences between us and Kent. From what I remember of implementation patterns, in his tradition, the emphasis is on the classes. Interfaces are secondary to make things a little more flexible (hence the 'I' prefix). In our world, the interface is what matters and classes are somewhere to put the implementation.

In particular, there seems (in the London tradition) to be an emphasis on the interfaces between the test subject and its collaborators.

I've been recently reviewing Wirfs-Brock/Wilkerson's description of the Client/Server model.

Any object can act as either a client or a server at any given time

As far as I can tell, everybody has always been in agreement about how to design tests that evaluate whether the test subject implements its server responsibilities correctly.

But for the test subject's client responsibilities?  Well, you either ignore them, or you introduce new server responsibilities to act as a proxy measure for the client responsibilities (reducing the problem to one we have already solved), or you measure the client responsibilities directly.

Mackinnon 2008 reported that extending the test subject with testing responsibilities was "compromising too far", and John Nolan had therefore challenged the team to seek other approaches.

Reflecting in 2010, Steve Freeman observed: 

The underlying issue, which I only really understood while writing the book, is that there are different approaches to OO. Ours comes under what Ralph Johnson calls the "mystical" school of OO, which is that it's all about messages. If you don't follow this, then much of what we talk about doesn't work well. 

Similarly, Nat Pryce:

There are different ways of designing how a system is organised into modules and the interfaces between those modules....  Mock Objects are designed for test-driving code that is modularised into objects that communicate by "tell, don't ask" style message passing.

My take, today, is still in alignment with the mockists: the TDD of the London school is the same TDD as everybody else: controlling the gap between decision and feedback, test first with red green refactor, and so on.

The object designs are different, and so we also see differences in the test design - because tests should be fit for purpose.

 

TDD: Tabula Rasa

What does Test Driven Development look like when you are staring at a blank page?

I was reminded again this week that there a lot of different approaches that one might use, and they don't all answer that question the same way.  So let's try a better question: what does Test Driven Development look like when I am staring at a blank page.

It'll help to have a specific example to work from, so lets consider something like a model for a calculator app; something that will eventually have buttons for input, and a display for output.  The kinds of tests that we expect to end up with ask questions like "after I push buttons in this sequence, what information is on the display?"

You will, I hope, recognize that this is a "toy" problem.  It's not very big.  We don't need to worry about integrating with anything else.  The domain is general and familiar.  We can probably make a fair bit of headway by starting with a small number of "buttons", and then extending our model to support a "scientific calculator" or a "programmer calculator".

Furthermore, I'm going to whistle on past the open issues of how "button presses" become inputs to the model, or how outputs from the model appear on the display.  So out of the gate, before I've even written anything down, I'm carving up the bigger problem into modules, and exercising judgment about which are "important".

But the page is still blank.  Now what?

And if we were stuck more than a minute, I'd stop and say, "Kent, what's the simplest thing that could possibly work?" -- Ward Cunningham, 2004

My immediate goal is to crack through the analysis paralysis and writers block to get something/anything into play.

Two features here: first of all, because this is a "programmer test", I'm going to reach immediately for whatever language I plan for the production code.  That's one less thing I need to worry about as I context shift between design and checking for mistakes.

The second is that my design criteria is "easy to type".  I don't (yet) need to worry about whether I want to decouple these tests from a specific implementation.  I don't (yet) need to worry about whether I want to separate the specification from the test framework (if any).  I don't (yet) need to worry about code style, or physical design.  I'm just boosting myself past the point of static friction.

Choosing something other than a trivial behavior is common at this point.  I normally get away with it because faking a complicated behavior is not significantly harder than faking a simple behavior, and what I get in exchange is a chance to experience describing a more complicated check, so that I don't get deeply invested in the wrong interfaces.

Now we have code on the page, and the "RED" task is happening, and I can fuss over things like getting arguments in the right order for my test framework calls, and do I want to use a different representation of the data to make the intent of the test clearer, and are the reports we get when the test fails what we expect them to be, and so on.

There's a bunch of saw sharpening that makes sense now; after you have real code on the table to argue about, but before you are deeply committed to the specifics of the design.

Or we can judge that this design should be considered disposable, with the expectation that it is going to just act as a place holder until we gathered more evidence about what the longer lived test design should look like

And when we finally bored with the pre-flight rituals? Fake it to get the green test to red in a minimal about of all clock time (we already know that's going to be easy to type because we've written the same expression in the return statement).  And get the hustle on.

Mock Object Bibliography

• 1989 Assuring Good Style for Object-Oriented Programs 
• 1989 A Laboratory for Teaching Object-Oriented Thinking 
• 1998 Tell, Don't Ask
  
• 2000 Endo-Testing: Unit Testing with Mock Objects
• 2004 Mock Roles, not Objects
  
• 2006 Evolving an Embedded Domain-Specific Language in Java 
• 2008 The End of Endo-Testing?
  
• 2009 Using Mock Objects and Tests to Design Role-Based Objects 

Primitive Obsession Bibliography

• 2005 https://www.jamesshore.com/v2/blog/2005/primitiveobsession
• 2005 https://chriswheeler.blogspot.com/2005/05/my-favourite-smells.html
  
• 2007 https://grabbagoft.blogspot.com/2007/12/dealing-with-primitive-obsession.html
  
• 2011 https://blog.ploeh.dk/2011/05/25/DesignSmellPrimitiveObsession/
  
• 2013 https://wiki.c2.com/?PrimitiveObsession
  
• 2013 https://fsharpforfunandprofit.com/posts/designing-with-types-single-case-dus/
  
• 2013 https://blog.thecodewhisperer.com/permalink/primitive-obsession-obsession
  
• 2015 https://blog.ploeh.dk/2015/01/19/from-primitive-obsession-to-domain-modelling/
• 2015 https://www.industriallogic.com/blog/multiple-asserts-are-ok/
• 2018 https://softwareengineering.stackexchange.com/questions/365017/when-is-primitive-obsession-not-a-code-smell