BDD and soap operas

Long before BDD was a thing, there was soap opera testing. This exaggerates and complicates the usual test scenarios in the way that television soap operas exaggerate and complicate real life. It has a high rate of success in revealing important, but often unanticipated, scenarios.

Car rental soap opera

"A customer named Marick hires a car for a three-day business trip. (This, by the way, gives him enough rental points to reach Preferred status.) Midway through the rental, he extends it for another week. Several days later, he calls to report the car has been stolen. He insists that the Preferred benefit of on-site replacement applies, even though he was not Preferred at the start of the rental. A new car is delivered to him. Two days after that, he calls to report that the "stolen" car has been found. It turns out he'd mis-remembered where he'd parked it. He wants one of the cars picked up and the appropriate transaction closed. Oh, and one other thing: the way he discovered the mislaid car was by backing into it with its replacement, so they're both damaged..."

The above exotic scenario leads you into thinking about the following requirements:

• Upgrading to Preferred status during a rental
• Extending a rental
• Rental of two cars simultaneously
• Handling a stolen car
• On-site replacement of a car
• Undoing on-site replacement
• Undoing handling of a stolen car
• Return of a damaged car

Although "soap opera" is a nicely descriptive term for complicated test scenarios, it implies a strong element of exaggeration. The reality is that real-life is often more complex than any soap opera, and it turns out that the in-depth rules for many business and technical domains are significantly more complex and strange than they appear at first sight.

Application window size/position soap opera

Jan Mikovsky has an excellent example of how what looks like a straightforward design scenario is actually a very deep rabbit hole:

Users like applications that remember the state and position of windows across application sessions. They can pick a window arrangement they like, close the app whenever they want, and next time have everything just the way they like it. In the case of the Microsoft Windows APIs (both Win32 and .NET), the platform doesn't provide any built-in support for remembering window position. The platform documentation blithely tells you to do this work yourself, and sort of implies it won't be very hard. Hah.

 

[...Insert iterations 1 - 4 here...]

 

Designer: You are one tough customer. Fine: whenever the user puts the window into the normal or maximized state, we'll remember this as the preferred state. Then, when the user closes the window, we save this preferred state (regardless of what state the window is currently in). Satisfied?

User: Not by a long shot. You see, I have a laptop. I've also got this external monitor on my desk—a monitor whose dimensions are different than those of the laptop's built-in screen. If I close the application when the laptop is docked, then reopen the application when the laptop is undocked, the application tries to come up in a position that no longer makes sense. Sometimes I can't even get to the window with the mouse because the window comes up off-screen.

Designer: Crap. Okay, whenever we're recording the user's preferred position for the window, we'll also save the current dimensions of the monitor itself. Then, if the app is opening and the monitor's dimensions have changed, we'll do our best to interpolate a meaningful position for the window in the new monitor dimensions.

User: This helps a bit, but it's not perfect. Each time I move between the docked and undocked state, the window position shifts a bit. I really want the window to be one size when I'm undocked, and a different size when I'm docked.

[...Insert more iterations here...]

User names soap opera

Patrick McKenzie has another good example regarding developer myths about people's names:

• [..List of 30 myths...]
• I can safely assume that this dictionary of bad words contains no people’s names in it.
• People’s names are assigned at birth.
• OK, maybe not at birth, but at least pretty close to birth.
• Alright, alright, within a year or so of birth.
• Five years?
• You’re kidding me, right?
• Two different systems containing data about the same person will use the same name for that person.
• Two different data entry operators, given a person’s name, will by necessity enter bitwise equivalent strings on any single system, if the system is well-designed.
• People whose names break my system are weird outliers.  They should have had solid, acceptable names, like 田中太郎.
• People have names.

Once you start looking for soap opera scenarios to test your designs and implementations, you'll find them everywhere. From Ellen Ulmann's excellent book "Close to the Machine":

Human thinking can skip over a great deal, leap over small misunderstandings, can contain ifs and buts in untroubled corners of the mind. But the machine has no corners. In the painstaking dissection of the specification, line by code line, the programmer confronts an awful, inevitable truth: the ways of human and machine understanding are disjunct.

One of BDD's goals is to focus on business processes and system behaviour without worrying about the implementation details. This is one of its key differences to TDD. So soap opera testing fits very neatly with BDD. You create a fixed set of characters that are then subjected to various events - in a way, each soap opera test scenario is like an episode in a television soap opera. It's a valuable tool to add to your toolbox.