Recently, in the mailing for Steve Freeman and Nat Pryce’s book Growing Object-Oriented Systems Guided by Tests, I followed a discussion that included this comment:

I guess the skill is knowing in what makes as small as possible but valid slice (as you say in the book)

Even though I’ve written before about splitting stories, I have refined my ideas about how to deliver a useful, significant, but small slice of software. I use a simple technique which I describe this way:

1. Write out any, and I mean any, meaningful end-to-end scenario in detail with concrete values at every step.

2. Now that you’ve chosen one real scenario, go to each step in that scenario and ask the question, “What would I need to assume to eliminate this step?” If you find those assumptions make for a reasonable scenario, then use that assumption to simplify the scenario.

3. Repeat step 2 until exhausted or unable to come up with a simplifying assumption with five minutes’ thought.

I’ve used the example of online bill payment in many of my classes and applied this algorithm. You’d be surprised how simple, but useful a bill payments system one can build.

In fact, let’s look at this example in a bit more detail.

What does a typical bill payments system look like? I imagine that TD Canada Trust has a fairly representative system, so I’ll use that as my example.

First, select the “Pay Bills” option.

Next, select the account to use to pay the bill.

Next, select the bills you’d like to pay. Once in a while, I want to pay multiple bills at once, such as when my business has to pay the property taxes on a handful of rental properties.

Next, enter the amount you want to pay, the date on which to pay it, the account from which to pay it (why again?) and whether you want to repeat this payment automatically.

Verify the payment details: the amount, the account, the creditor, the date, and the system schedules the payment.

From this, I can describe the scenario in a form that looks like an executable example:

Pay a bill online

• Given that Joe has already logged in
• Joe says "I want to pay a bill"
• Joe selects chequing account 12345 from which to pay the bill
• Joe selects Visa bill with account ending in 2222 as the bill to pay
• Joe says "I want to pay $5,000"
• Joe selects a date 14 days from now as the date on which to pay the bill
• Joe selects "only once" as the frequency with which to pay the bill
• After Joe sees a summary of the bill payment he has asked to schedule, he says "I confirm that I want to pay this bill"
• Now the system schedules to pay the bill as requested and sends Joe an email to confirm the transaction with a link to cancel or change the scheduled payment

Apart from the numbers, this scenario perfectly accurately reflects how I pay my bills online, although I only wish TD Canada Trust would send me the confirmation email I threw in as the system’s response. We have completed step 1 of the algorithm: we have specified a complete scenario with concrete values at every step.

You'll notice that we didn't specify Joe's username and password. We don't intend to re-test logging in here, so we don't bother with those details. We will have tested that elsewhere.

Now we move to step 2 of the algorithm: looking for assumptions we could make about paying a bill online that would eliminate steps in the process. To do this, we have to be prepared to sacrifice any semblance of a decent user experience. Don’t worry: once the Walking Skeleton runs, you’ll be able to add all the bells and whistles that will make this feature a pleasure to use. For now, we want to eliminate any detail that distracts us from connecting our feature to the key interfaces it must deal with. In this example, I know I want to expose an HTTP interface to clients (eventually the web) and that I need to connect to the Big Ugly Banking System, but beyond that, I don’t know that anything else matters. Within this context, then, we can start making our simplifying assumptions.

That is, until someone remembers that, being a bank, we need to keep a strictly accurate record of all transactions. That means we should add a final step to the scenario: the system records the transaction in its log. While some might consider this a superfluous detail, banking regulators would call it quite essential, and so I find it hard to ignore. This means that we have a third essential interface to which to connect: the transaction logging facility. For our purposes, I’ll assume that we have one and that it has the usual properties: transaction posting date, description, and debit or credit amount, who performed the transaction and when.

This itself makes me ask whether we need to log the transaction yet, because in our scenario we’ve scheduled a payment, and not made one. Scheduling a transaction leads to issues of canceling, editing, and building a process that completes the transaction on the day the customer scheduled it. This leads to our first simplifying assumption: Joe pays the bill immediately.

This simplifies the scenario because we no longer need Joe to tell the system when to pay the bill: the system always pays the bill immediately. Our revised scenario looks like this:

Pay a bill online

• Given that Joe has already logged in
• Joe says "I want to pay a bill"
• Joe selects chequing account 12345 from which to pay the bill
• Joe selects Visa bill with account ending in 2222 as the bill to pay
• Joe says "I want to pay $5,000"
• Joe selects "only once" as the frequency with which to pay the bill
• After Joe sees a summary of the bill payment he has asked to schedule, he says "I confirm that I want to pay this bill"
• Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

I like to start at the top and look for simplifying assumptions. First, I see that Joe has to select the account from which to pay the bill, which implies that the system presents a list of accounts to Joe, which we recognize we need to do, but not in the Walking Skeleton. Ultimately, Joe simply needs to specify the account number to debit to pay the bill, so for now we’ll make him type that in. Our revised scenario looks like this:

Pay a bill online

• Given that Joe has already logged in
• Given that Joe has already logged in
• Joe says "I want to pay a bill"
• Joe says "I want to pay from account 12345"
• Joe selects Visa bill with account ending in 2222 as the bill to pay
• Joe says "I want to pay $5,000"
• Joe selects "only once" as the frequency with which to pay the bill
• After Joe sees a summary of the bill payment he has asked to schedule, he says "I confirm that I want to pay this bill"
• Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

Next, I see that Joe again has to select the bill to pay, which implies that the system presents a list of bills to pay. We could simplify this by requiring Joe to enter the payee identification number and the account number, even though this means saddling Joe with knowledge of payee identification numbers. In particular, the system neither has to store nor present a list of bill payees, and Joe doesn’t need to register a creditor before paying them.

I'm making up this notion of payee identification numbers because I don't know how banks really implement this. I imagine whatever they do, it boils down to companies registering as payees for bill payments, which results in issuing them some kind of identification number. If some kind soul wants to educate me on how this really works, I'd gladly edit the article to bring it closer to the banking industry's real implementation.

Our revised scenario looks like this:

Pay a bill online

• Given that Joe has already logged in
• Given that Joe has already logged in
• Joe says "I want to pay a bill"
• Joe says "I want to pay from account 12345"
• Joe says "I want to pay to payee number 66666"
• Joe says "I want to pay to account number 2222"
• Joe says "I want to pay $5,000"
• Joe selects "only once" as the frequency with which to pay the bill
• After Joe sees a summary of the bill payment he has asked to schedule, he says "I confirm that I want to pay this bill"
• Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

Next, I notice that Joe has to specify the amount to pay, and I can’t think of how to eliminate that detail without complicating matters. It does make me think about potential future features, such as “pay balance off in full” and “pay minimum payment required”, which I note down before returning to this scenario. Joe will simply have to tell us exactly how much to pay towards the bill.

Next, I notice that Joe has to confirm that he only wants a one-time payment. We can eliminate this detail by assuming that Joe can only pay the bill once. We know that customers want recurring payments, but that only distracts us from implementing the Walking Skeleton. We can eliminate this step, and our revised scenario looks like this:

Pay a bill online

• Given that Joe has already logged in
• Joe says "I want to pay a bill"
• Joe says "I want to pay from account 12345"
• Joe says "I want to pay to payee number 66666"
• Joe says "I want to pay to account number 2222"
• Joe says "I want to pay $5,000"
• After Joe sees a summary of the bill payment he has asked to schedule, he says "I confirm that I want to pay this bill"
• Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

Next, I notice that Joe has to confirm the bill payment before the system will process the payment. While this step might seem essential for security reasons, remember that we don’t necessarily have a graphical web interface for our Walking Skeleton implementation, and so we might not even have the opportunity to ask for confirmation of the bill payment. On this basis, we eliminate this step by assuming that Joe has looked over the details before pressing the button to pay the bill. Our revised scenario looks like this:

Pay a bill online

• Given that Joe has already logged in
• Joe says "I want to pay a bill"
• Joe says "I want to pay from account 12345"
• Joe says "I want to pay to payee number 66666"
• Joe says "I want to pay to account number 2222"
• Joe says "I want to pay $5,000"
• Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

I can’t see any further simplifications, so I choose to stop here. I suspect this constitutes a close-to-minimal protocol for the “pay a bill online” feature. The programmer in me sees this as a single message, which pleases me, because of the simplicity of the interaction. The customer in me can see clearly all the extra stories we need to complete to make this feature available for public use, which makes planning easier. It feels like a win for everyone, except perhaps for Joe, who has a crappy interface to work with.

Now that we have a Walking Skeleton bill payment feature, we can identify the stories we want to deliver beyond the simplest case, and can decide which ones we need to roll this feature out to paying customers.

• Let Joe choose from a list of available payees which company to pay
• Remember the payees that Joe has previously paid and present them as “favorites” so he doesn’t have to search for them
• Remember the payee accounts that Joe has previously paid so that he doesn’t have to enter them each time
• Let Joe delete accounts he no longer needs to pay
• Give Joe the option of paying the minimum payment required by the payee
• Give Joe the option of paying the full balance owing
• Let Joe schedule his payment in the future
• Let Joe cancel pending payments
• Let Joe change pending payments
• Send a reminder to Joe to pay a bill he has paid at least three of the past six months (try to detect a recurring payment)
• Let Joe schedule a payment to recur every month (same day each month)
• Notify Joe in advance of automatically detected recurring payments and ask him if he wants us to pay the bill for him
• When emailing Joe about a bill payment, include links to review the scheduled payment, change it, or cancel it, if appropriate

I imagine we could come up with more together, but I find one common thread with all these stories: once we implement the Walking Skeletion, we can implement most of these stories independently of the others. We know that more independent stories means greater opportunities to change priorities as needed as well as greater opportunities to drop features in favor of other more lucrative options. Once again, everyone wins.

Would you like to work with J. B. Rainsberger to realize revenue sooner and lower costs from delivering software? Schedule a workshop with J. B. today.

I enjoy collaborating on decisions, but only with groups that agree to use a technique I refer to as consent-based decision making. I might not use that term exactly as the coiners intended, so let me explain what I mean. I characterize consent-based decision making by putting forth a proposal, then looking for reasoned objections. When no-one raises such an objection, we accept the proposal. I find this style of decision making quicker, easier, and better for team unity than typical approaches.

Consent-based decision making contrasts sharply with a typical decision-making exercise, which tends to follow these steps:

1. Present a need or problem.
2. Present options.
3. Solicit more options from the group.
4. Discuss the merits of each option in detail.
5. Propose solutions.
6. Combine the proposed solutions into a kind of hybrid solution to which everyone can assent.
7. Ask for any last-minute objections.
8. Decide.

I feel tired trying to make decisions this way, and it seems that the fatigue rises with at least the square of the number of people involved. Not only do I find it difficult to make decisions this way, but that difficulty encourages me to exclude people who might otherwise have valuable input. It puts me in a place of wanting to prune ideas, rather than generate them. You can understand why I’d want to avoid this kind of consensus building.

Some objections

When I have taught consent-based decision making to my clients, some of them have pointed out that it leads to a particularly negative culture: “Don’t bring me problems; bring me solutions.” I agree that, practised mindlessly, that could happen, but because I insist we practise mindfully, I think we can avoid this problem. Still others have pointed out that this style of decision-making stifles creativity because it intimidates people who want to point out a flaw in a proposal without necessarily having a better proposal. Again I agree, but we can mitigate this risk by looking at one of consent-based decision making’s greatest strengths: separating generating ideas from selecting a solution.

I remember dozens of meetings in which I participated in making decisions by building consensus, specifically how inconsistently engaged I felt. I would enter some of these meetings with a desire to generate ideas, brainstorm, and explore solutions; and I would entry other of these meetings tired of sifting through ideas, craving to decide on a course of action. I can’t tell you why I felt the way I felt, but rather just that it varied, and that I felt it strongly. Sometimes I wanted to expand the solution space, and other times I wanted desperately to contract it. So far, I don’t see a problem with that, but there are, of course, other people.

When you and I enter a decision-making meeting with different goals, we create problems for each other. When you want to generate ideas and I want to select a solution, we fight for air time, for space, and indeed for life… at least, it feels that way to me. I struggle to bring us to a sensible solution, and as my wish comes close to coming true, you trample on it with yet another pie-in-the-sky idea. Worse, your idea might fit perfectly, but I simply won’t see it that way. I will interpret your every new idea as an attempt to prolong the agony, whereas you will interpret my every attempt to choose a solution as an attempt to shut you down. Result? War. Root cause? Cross purposes. Remedy? Alignment. (Surprised?)

Two goals, two meetings

Consider, instead, having two separate meetings: one to generate proposals, and one to select a proposal. You might find that that helps.

In the first meeting, we generate ideas, brainstorm, solicit opinions, run impact studies… whatever we need to do to generate proposals. The people who come to this meeting might or might not care about making the decision. Whatever happens, we can feel certain that whoever shows up wants to lend their ideas to the group, and most importantly, we ignore any attempt at choosing a solution. We agree in advance to ignore them, because we have a different goal in this meeting. We agree not to chastise people for attempting to choose a solution because they form part of our natural impulse to jump to a conclusion. We agree to recognize each other’s humanity by allowing each other to compare or rank solutions, but we generally ignore those attempts in a quiet, friendly manner. (See Ask Why, But Don’t Answer for an explanation.)

The second meeting starts with a proposal. The group may ask clarifying questions, but by now we shouldn’t need to ask too many. The Proposer than asks the group to vote, which the group does by signaling thumb up, sideways, or down. A thumb up means “I accept the proposal”. A thumb sideways means “I will go with the rest of the group”. I thumb down means “I reject the proposal”. Of course, if you reject the proposal, then you must make a counter-proposal right away, otherwise the group feels free to ignore your vote. The group repeats this process until either it makes a decision or reaches a deadlock. If it reaches a deadlock, then we immediately adjourn the meeting and schedule another one to explore the competing proposals in depth. Why schedule another meeting? In part, to discourage people from rejecting a proposal just for the sake of rejecting it, and to give those people an opportunity to sleep on it before beginning another round of brainstorming.

No silver bullet

Naturally, people could abuse this system. And yes, when we have to make particular tough decisions, this system could take longer than the consensus-building approach. Even so, for more routine decisions, consent-based decision making works more quickly and easily, and I’d rather make easy things easy and hard things possible than optimize for the hard decisions.

It surprises me, from time to time, how much I still need to justify test-driven development to prospects and would-be course attendees. Many feel that TDD has crossed the chasm, while others still see TDD as a cultish practice worth marginalizing. I take some blame for those who find TDD cultish, because until now I haven’t had a strong, sensible, theoretical basis to justify TDD as an idea. I could do no better than “it works for me” or “my friends like it”. That has changed since I’ve started giving my talk “Introduction to Agile with the Theory of Constraints” in which I use concepts from Theory of Constraints to motivate the practices of agile software development, notably those of extreme programming. If you buy in to ideas from Theory of Constraints or Lean Manufacturing, then I think I now have a stronger argument to justify the core programming practices in extreme programming in particular and agile software development in general. I don’t even need all of the Theory of Constraints but rather a simple appeal to fundamental concepts in Queuing Theory.

Queuing Theory?

Yes, Queueing Theory. (And I don’t plan to capitalize that any longer.) I don’t proclaim to have any particular expertise in this area, but I have already seen how to use queuing theory ideas in optimizing network-based systems, and I see no reason we couldn’t extend that to software delivery systems. Better, I only need to appeal to a single idea from queuing theory to make my point.

Given a process B, which follows a process A, sometimes in performing B we need to perform some of A again. We can remove the need to rework by taking some portion of process B and performing it before process A¹.

This merits a diagram. If we have this problem

then we can solve it by doing this

and the resulting system will work more efficiently by removing wasteful rework. I assume here that we derive no significant benefit from the rework itself, which I suppose I must justify, but let’s not ruin a good story with the truth. Here I’ve described the general problem, and by applying it to software development, I can… well, I find it more effective if I save the punchline for the end.

Winston Royce, 1970, revisited

I imagine you know this diagram

and appreciate that Royce wrote in his now infamous paper that this single-phase waterfall is risky and invites failure. If you don’t appreciate that, then I cannot strongly recommend enough your reading the original paper in its entirety, rather than stopping after page 2 as most people have done².

We can apply the queuing theory result I’ve just cited to this diagram and generate some interesting conclusions. I’ll start by focusing in on this portion of the system

We write code, then we test it. Sadly, we occasionally find a bug³ which makes us change the code we wrote after we thought we’d finished it. That makes a loop of the type we can unravel with our queueing theory result.

Since “coding” is process A and “testing” is process B, we need to do some testing before we start coding.

It doesn’t take long for this to become a virtuous loop where we writing only the code we need to write in order to pass the tests we write.

I use the term test-first programming to describe this cycle⁴. When we practise test-first programming, we design as much detail as we can before writing the first test, then use the tests to help us type in our implementation correctly. Most teams most of the time can use test-first programming to reduce their defect mistake count to near zero, which increases their productivity and improves their ability to deliver, by helping them waste less time agonizing over whether to fix mistakes late in a release. I started this way in 2000 when I first discovered JUnit and stopped making silly mistakes in the code I wrote, which I found significantly beneficial in helping me code more confidently. I still designed most of what I built mostly up front.

After a while, though, I recognized a new process loop: I found some parts of my design difficult to test, or I found some parts of my design didn’t fit together when I tried to type them in.

Returning to our queuing theory result, since “designing” is process A and “doing test-first programming” is process B, we need to do some test-first programming before we start designing.

It doesn’t take long for this to become a virtuous loop where we check our design ideas as we think of them and implement only the parts of the design we can justify needing. When we include refactoring in our practice, we can confidently “under-design” compared to the level of design we expect to need by the end of a task, which I believe amounts to designing appropriately for the code we need to implement right now. This virtuous loop combines test-first programming and evolutionary design, including guiding principles like “you aren’t gonna need it” and the four elements of simple design into test-driven development, where we check our implementation by running tests and we check our design ideas by writing tests.

Where test-first programming helps most teams most of the time reduce their mistake count to near zero, test-driven development helps them reduce their design inventory—mostly code that gets in our way because it doesn’t actively help us deliver a feature—to near zero. This further increases productivity and improves their ability to deliver by helping them waste less time agonizing over design problems they find costly to fix. I waited until I’d spent an entire release practising test-first programming before doing more test-driven development. My transition consisted of trying to do less and less up-front design for each task, letting myself feel comfortable with each new step. Within two years I estimate I designed about 5% as much up front as I did before I started practising test-first programming. I can’t measure the corresponding improvement in my design, but I look back at projects that took 3 months before I practised test-driven development that I now feel confident I could complete—truly complete—in one week. Of course, we can’t stop here!

Enter our friend analysis. To simplify the discussion, I will treat analysis as “discovering the features we want in our software” without forcing myself to state too precisely how that happens⁵. Once again, we have our familiar situation.

Once again, we face the situation where in the process of implementing features we discover new features we need, current features we don’t need, and learn new things about features we know we need to build. This adds to our analysis, meaning that we should try test-driving some features before we try to implement others.

It doesn’t take long for this to become a virtuous loop in which our desire to implement (and deliver!) features drives them ever smaller, as we extract more concentrated value out of each one⁶. When we implement feature 12 we learn something about features 23, 30 and 52. We might decide not to deliver feature 30 any more. We might decide to expand feature 23 to encompass a few more key cases. We might decide to rush feature 52 to the top of the pile. Most teams most of the time find that this cycle helps them reduce the number of rarely- or infrequently-used features in their system⁷. This yet again increases productivity and improves their ability to deliver meaningful software to their stakeholders by eliminating the time wasted on delivering too much of a feature too soon, the time wasted on entire features we thought we needed but realized we don’t, and the time wasted arguing about what a feature means, rather than writing examples together: business-oriented tests that describe how a feature works in enough detail for the business and technical project community to agree on the conditions of satisfaction for delivering the feature.

I call this behavior-driven development, and refuse to spell it with the u that provides as much value to the word as your appendix does to your body⁸.

Once again, I didn’t coin the phrase, and some might argue against the way I use it, but I find it apt. This cycle include practices like business and technical people writing examples together, feature injection, feature splitting, and value-based (rather than cost-based) planning.

At this point, I think I’ve done my job. I believe I’ve justified not only test-first programming or test-driven development, but full-on behavior-driven development, using only a single result from fundamental queuing theory. I’ve made only a single assumption—that we agree on the appropriateness of applying queuing theory to a software development system. I’ve tried to add as little as possible to my reasoning in order to keep it as context-free as possible. As a result I claim that most teams most of the time will benefit from moving along the path from code-and-fix to test-first programming to test-driven development to behavior-driven development.

Now, for homework, what happens when we consider these processes?

Surely at least one you’ve needed to deliver more features for software you’d already deployed. How well does that work? What problems do you encounter? What if you applied our new favorite queuing theory result to that rework loop?

¹ I really need a citation for this, and when I find it, I will place it here.

² I digress, but I really can’t help myself on that one.

³ Also known as defect or, for the truly congruent, mistake.

⁴ Clearly I didn’t coin the phrase, but I know many people who treat “test-driven development” as a simple renaming of “test-first programming”, and I believe making a stronger distinction adds real value to the conversation.

⁵ I don’t think “gathering requirements”, as though we could pick them like berries, fits as a metaphor. I like “trawling for requirements”, which I believe I first read in Mike Cohn’s User Stories Applied.

⁶ We can easily apply the “Pareto Distribution” here in that we can deliver 80% of the value from implementing 20% of the feature.

⁷ You recall that Jim Johnson of the Standish Group reported in 1994 that 45% of developed features are “never used”. As I recall, only 7% of features were used very frequently.

⁸ My Canadian and British brethren and sistren be damned. I assert my right as a Canadian to choose the British spelling when I prefer it and the American spelling when it saves me time.

I added more to this article on September 18, 2009.

On May 21, 2006, I wrote the world’s shortest article on Behavior-Driven Development. Although the title links to the entire article, it is so short that I can reproduce it here.

What is Behavior-Driven Development (BDD)?

It is Test-Driven Development (TDD) practiced correctly; nothing more.

At the time, I wrote this in anger, for reasons that I’m too tired to get in to just now (it is 4:30 AM on the last day of Agile 2006), but I wanted to share with you that my anger is changing to some more positive emotion regarding this topic.

The fact that BDD and TDD are equivalent—isomorphic, even—has its good points and bad points. I am unclear at the present moment whether the good outweigh the bad or the other way around.

What I dislike about the existence of two (perhaps three or more) different names for the same thing is that it can confuse people and divide them. Think of a single language written in two alphabets: while the speakers understand one another, they cannot read one another’s literature. I would hate to see that happen.

What I like about it is that we have two (perhaps three or more) standard approaches to explaining the technique that suit different audiences. To some, the word “test” resonates well, and to others, the words “behavior” or “example” resonate well. Rather than haphazardly sprinkling the word “behavior” into conversations about TDD, we can use an entire, cohesive vocabulary to explain TDD to someone who prefers to talk about behaviors over tests. I imagine this would help.

I would like to thank the people in room 2411 of the Hyatt Regency in Minneapolis for their willingness to participate in a spirited debate on this topic. It was tiring, and it was late, but I found it worth the effort.

Times have changed

In the time since I first wrote this article, BDD has evolved and my opinion of it has evolved as well. I now see how BDD ideas map well to the way I deliver features, complete with Feature Injection and the inner BDD design cycle. The BDD community have described how they set up a pull system for features, which I’ve been doing for years. As always seems the case, we had much more in common with one another than we originally thought!

Thanks to all the BDDers who have patiently worked with me on this unification, even when they didn’t know they were doing it: Dan North, Chris Matts, Olav Maassen, Aslak Hellesøy and Liz Keough.

Recently, “Guest” commented about my Agile 2009 tutorial, Integration Tests Are A Scam. “Guest” wrote this:

A Mars rover mission failed because of a lack of integration tests. The parachute system was successfully tested. The system that detaches the parachute after the landing was successfully – but independently – tested. On Mars when the parachute successfully opened the deceleration “jerked” the lander, then the detachment system interpreted the jerking as a landing and successfully detached the parachute. Oops. Integration tests may be costly but they are absolutely necessary.

I don’t doubt the necessity of integration tests. I depend on them to solve difficult system-level problems. By contrast, I routinely see teams using them to detect unexpected consequences, and I don’t think we need them for that purpose. I prefer to use them to confirm an uneasy feeling that an unintended consequence lurks.

Let’s consider a clean implementation of the situation my commenter describes. I see this design, comprising the lander, the parachute, the detachment system, an accelerometer and an altimeter. A controller connects all these things together. Let’s look at the “code”, which I’ve written in a fantasy language that looks a little like Java/C# and a little like Ruby.

Ashley Moran has posted a working Ruby version of this example. If you speak Ruby, then I highly recommend looking at that example after you’ve read this.}

Controller.initialize() {               
  parachute = Parachute.new(lander)
  detachment_system = DetachmentSystem.new(parachute)
  accelerometer = Accelerometer.new()
  lander = Lander.new(accelerometer, Altimeter.new())
  accelerometer.add_observer(detachment_system)
}  
          
Parachute {
  needs a lander
  
  open() {
    lander.decelerate()
  }             
  
  detach() {
    if (lander.has_landed == false)
      raise "You broke the lander, idiot."
  }
}      
                        
AccelerationObserver is a role {
  handle_acceleration_report(acceleration) {
    raise "Subclass responsibility"
  }
}
                        
DetachmentSystem acts as AccelerationObserver {
  needs a parachute
  
  handle_acceleration_report(acceleration) {}
    if (acceleration <= -50.ms2) {
      parachute.detach()
    }
  }
}               
 
Accelerometer acts as Observable {
  manages many acceleration_observers
                                    
  report_acceleration(acceleration) {
    acceleration_observers.each() {
      each.handle_acceleration_report(acceleration)
    }
  }
}
 
Lander {
  needs an accelerometer  
  needs an altimeter
  
  decelerate() {
    // I know how much to decelerate by
    accelerometer.report_acceleration(how_much)
  }
}
 

I need to test what happens when I open the parachute. The lander should decelerate.

testOpenParachute() { 
  parachute = Parachute.new(lander = mock(Lander))
  lander.expects().decelerate() 
  
  parachute.open() 
}
 

Since this test expects the lander to decelerate, I have to test that. When the lander decelerates, the accelerometer should report its deceleration.

testLanderDecelerates() {                  
  accelerometer = mock(Accelerometer)
  lander = Lander.new(accelerometer)
  accelerometer.expects().report_acceleration(-50.ms2)
  
  lander.decelerate()
}
 

Since this test shows that the accelerometer can report acceleration of -50 m/s², I have to test that.

testAccelerometerCanReportRapidAcceleration() {
  accelerometer = Accelerometer.new()
  accelerometer.add_observer(observer = mock(AccelerationObserver))
  observer.expects().handle_acceleration_report(-50.ms2)
  
  accelerometer.report_acceleration(-50.ms2)
}                                          
 

Since this test shows that any acceleration observer must be prepared to handle an acceleration report of -50 m/s², I have to test that.

First, the general test for the contract of the interface:

AccelerationObserverTest {
  testAccelerationObserverCanHandleRapidAcceleration() {
    observer = create_acceleration_observer() // subclass responsibility
    this_block {
      observer.handle_acceleration_report(-50.ms2)
    }.should execute_without_incident
  }                                                      
}
 

Now the test for DetachmentSystem, which acts as an AccelerationObserver. What should it do if it detects such sudden deceleration? It should detach the parachute.

DetachmentSystemTest extends AccelerationObserverTest {
  // I inherit  testAccelerationObserverCanHandleRapidAcceleration()
  
  create_acceleration_observer() {
    DetachmentSystem.new(parachute = mock(Parachute))
    parachute.expects().detach()
  }
}
 

You might find that easier to read this way, by inlining the method create_acceleration_observer():

DetachmentSystemTest {
  testRespondsToRapidAcceleration() {
    detachment_system = DetachmentSystem.new(parachute = mock(Parachute))
    parachute.expects().detach()
    this_block {
      detachment_system.handle_acceleration_report(-50.ms2)
    }.should execute_without_incident
  }
}                              
 

Since this test expects the parachute to be able to detach, I have to test that. Now, detaching only works if we’ve landed. (I’ve simplified on purpose. Suppose the parachute can’t survive a drop from any height. It’s easy to add that detail in later.)

ParachuteTest {
  testDetachingWhileLanded() {
    parachute = Parachute.new(lander = mock(Lander))
    lander.stubs().has_landed().to_return(true)    
    this_block {
      parachute.detach()
    }.should execute_without_incident
  }
  
  testDetachingWhileNotLanded() {
    parachute = Parachute.new(lander = mock(Lander))
    lander.stubs().has_landed().to_return(false)
    this_block {
      parachute.detach()
    }.should raise("You broke the lander, idiot.")
  }
}
 

Hm. I notice that parachute.detach() might fail. But I just wrote a test that uses parachute.detach() and doesn’t yet show how it handles that method failing. I have to test that.

DetachmentSystemTest {
  testRespondsToDetachFailing() {
    detachment_system = DetachmentSystem.new(parachute = mock(Parachute))
    parachute.stubs().detach().to_raise(AnyException)
 
    this_block {
      detachment_system.handle_acceleration_report(-50.ms2)
    }.should raise(AnyException)
  }
}
 

Hm. So handling an acceleration report of -50 m/s² can fail. Who might issue such a right? The accelerometer. Since the detach system doesn’t handle this failure, I have to test what the accelerometer does when issuing an acceleration report might fail.

testAccelerometerCanRespondToFailureWhenReportingAcceleration() {
  accelerometer = Accelerometer.new()
  accelerometer.add_observer(observer = mock(AccelerationObserver))
  observer.stubs().handle_acceleration_report().to_raise(AnyException)
 
  this_block {
    accelerometer.report_acceleration(-50.ms2)
  }.should raise(AnyException)
}
 

It turns out that the accelerometer might fail when reporting acceleration of -50 m/s². When might it do that? When the lander decelerates. What happens then?

testLanderDeceleratesRespondsToFailure() {                  
  accelerometer = mock(Accelerometer)
  lander = Lander.new(accelerometer)
  accelerometer.stubs().report_acceleration().to_raise(AnyException)
 
  this_block {
    lander.decelerate()
  }.should raise(AnyException)
}
 

Hm. So decelerating could fail! All right, who causes the lander to decelerate? That code might fail. Oh yes… the parachute opening!

testOpenParachuteRespondsToFailure() { 
  parachute = Parachute.new(lander = mock(Lander))
  lander.stubs().decelerate().to_raise(AnyException)
  
  this_block {
    parachute.open() 
  }.should raise(AnyException)
}  
 

So opening the parachute could fail! We probably want to nail down when that happens. We have a test that shows us when:

testDetachingWhileNotLanded() {
  parachute = Parachute.new(lander = mock(Lander))
  lander.stubs().has_landed().to_return(false)
  this_block {
    parachute.detach()
  }.should raise("You broke the lander, idiot.")
}
 

So the parachute opening could cause it to detach because the lander hasn’t landed yet. I don’t know about you, but I think the parachute provides the most value when its helps the lander land, and not once it has landed. That tells me that someone, somewhere needs to handle the exception that detach() would raise, or at least prevent detach() from happening while the altimeter reads above a few meters off the ground.

testDoNotDetachWhenTheLanderIsTooHighUp() {
  altimeter = mock(Altimeter)
  altimeter.stubs().altitude().to_return(5.m)
  
  DetachmentSystem.new(parachute = mock(Parachute))
  parachute.expects(no_invocations_of).detach()
  
  detachment_system.handle_acceleration_report(-50.ms2)
  
  // ???
}
 

In writing this test, I see that in order to stop the detachment system from telling the parachute to detach, it needs access to the altimeter.

Integration problem detected. When I wire the detachment system up to the altimeter, even the collaboration test shows how to ensure that the parachute doesn’t detach in this kind of dangerous situation.

testDoNotDetachWhenTheLanderIsTooHighUp() {
  DetachmentSystem.new(parachute = mock(Parachute), altimeter = mock(Altimeter))
  altimeter.stubs().altitude().to_return(5.m)
  parachute.expects(no_invocations_of).detach()
  
  detachment_system.handle_acceleration_report(-50.ms2)
}
 

This means I have to add the following production behavior.

DetachmentSystem acts as AccelerationObserver {
  needs a parachute
  needs an altimeter // NEW!
  
  handle_acceleration_report(acceleration) {}
    if (acceleration <= -50.ms2 and altimeter.altitude() < 5.m) {
      parachute.detach()
    }
  }
}               
 

Integration problem solved with no integration tests. Instead, I have a bunch of collaboration tests, one important contract test, and the ability to notice things a systematic approach to choosing the next test, which I describe in the comments below. Any questions?

Dan Fabulich rightly jumped on me for using the phrase “an ability to notice things” just a little earlier in this article. I choose that phrase lazily because I didn’t want to patronize you by writing, “an ability to perform basic reasoning”. Oops. I thought about how I choose the next test, and I decided to take the time to include that here. Enjoy.

In this example, I used no magic to choose the next test; but rather some fundamental reasoning.

Every time I say “I need a thing to do X” I introduce an interface. In my current test, I end up stubbing or mocking one of those tests.

(See A sign you’re mocking too much for more about when I avoid interfaces and when I routinely create them.)

Every time I stub a method, I make an assumption about what values that method can return. To check that assumption, I have to write a test that expects the return value I’ve just stubbed. I use only basic logic there: if A depends on B returning x, then I have to know that B can return x, so I have to write a test for that.

Every time I mock a method, I make an assumption about a service the interface provides. To check that assumption, I have to write a test that tries to invoke that method with the parameters I just expected. Again, I use only basic logic there: if A causes B to invoke c(d, e, f) then I have to know that I’ve tested what happens when B invokes c(d, e, f), so I have to write a test for that.

Every time I introduce a method on an interface, I make a decision about its behavior, which forms the contract of that method. To justify that decision, I have to write tests that help me implement that behavior correctly whenever I implement that interface. I write contract tests for that. Once again, I use only basic logic there: if A claims to be able to do c(d, e, f) with outcomes x, y, and z, then when B implements A, it must be able to do c(d, e, f) with outcomes x, y, and z (and possibly other non-destructive outcomes).

I simply kept applying these points over and over again until I stopped needing tests. Along the way, I found a problem and fixed it before it left my hands.

If I can describe the steps well enough for others to follow – and I posit I’ve just done that here – then I don’t agree to labeling it “magic”.