Two Ways to Get Started with Behavior-Driven Development
Sometimes in software development, we get so wrapped up in the tech of things that we lose track of what we’re even talking about. Sometimes finding a common language that connects what devs are doing to the rest of the business is all it takes to take a product from interesting to customer-delighting.
An offshoot of domain-driven design and test-driven development, behavior-driven development (BDD) is dedicated to pairing business and customer interests with technical expertise. It uses simple syntax — Given this/these, When this happens, Then this/these will happen — to explain circumstances in a shared language that then can be converted into executable tests that are usually created before the code itself. BDD applies a combination of user stories and input language that is converted into specifications.
Much of the P3X: People, Product & Process Exchange conference in London focused on the evolution of agile testing and BDD because that’s precisely where the process intercedes the people and product for a positive change. Today The New Stack is going to share some of the process taught that are helpful to following behavior-driven design.
BDD All Starts with a Conversation
Spec Solutions’ Gáspár Nagy
Spec Solutions’ Gáspár Nagy described BDD as a testing tool that offers a shared sense of ownership.
“What are the pain points of the business? [To understand] what are their most important problems and see how BDD can have an impact on that. Say we don’t make deadline — see if BDD can help make scenarios business-readable so the business will see the course of sprints,” he said, continuing that BDD is all about leveraging tests to make you confident on your release days.
But how do we reach that shared sense of ownership? What are the consistent barriers to that communication?
“Hi Domain Experts, please tell me everything I need to know to build that software.”
Author of “Living Documentation by design, with Domain-Driven Design,” Cyrille Martraire pins the tail on the donkey as to where we start to miss the whole point of behavior-driven design. We understand it’s important to learn from our domain experts, but why is it difficult to start these conversations with our potential customers?
“We don’t speak the same language. They don’t have time for us. As the non-domain expert we have to see that time as precious,” Martraire explained.
He says it all starts with doing your homework before starting a conversation:
- Start with genuine curiosity
- Find the proxies for the domain experts — read the “bible” in field
- Create a checklist of potential precise and to-the-point questions
- Learn the vocabulary corpus of that domain
None of the above is a list of possible features. You are there to learn what the domain experts need. Your prep work is just to help make sure you haven’t forgotten anything and don’t waste their time.
Next, to make the most of this time, take loads of notes — adding comments that are clear to distinguish what are your thoughts versus their truth. And practice the Socratic Method of active listening, repeating phrases back to them verbatim “What I am hearing you say is…” or “What did you mean by…” for clarification. Don’t be afraid to challenge their assumptions respectfully.
Next get into the nitty-gritty of the specific needs of that specific prospect or customer, always asking: Why? What’s the goal?
Then, as BDD is all about creating good, real-world examples, Martraire recommends clarifying everything with “I think we agree, but just in case to be 100 percent sure, we should spend a few minutes to craft an example together.
“Usually that’s when the conversation really starts.”
Martraire says this is the best way of discovering the early “unknown unknowns” as soon as possible. Ask for concrete examples. He works with big French banks, so he definitely wants PDF documents as examples of contracts with genuine data. He admits this often is the most time-consuming part of your domain discovery, but you should insist.
But that doesn’t mean all domain experts are of the same quality. This is why you need to interview more than one.
“The worse domain expert is the one whose expertise was built for the intricacies of existing systems,” Martraire said, while “The best expert has had an emotional loss from losing something.”
And with that, finally, he reminds us that you don’t want to forget that the code is a domain expert unto itself — telling you what it wants and what isn’t working already.
The entire process of behavior-driven design and development is about empathy and listening. Now, we share some tricks from P3X speakers for how to facilitate those often difficult conversations with divergent mindsets, backgrounds, skill sets, and communication styles.
OOPSI for BDD Discovery and Specification by Example
BDD acts very much like sentence diagramming, a dying art in English grammar. It’s about mapping important pieces in a logical way to make sure all aspects of the business understands. As Agile Coach Jenny Martin said, it’s about:
- Given — preconditions for behavior (can be multiple Givens)
- When — the really important action bit (can only be one When)
- Then — describes the postcondition (can be multiple Thens)
Martin described GWT as “a syntax and parlance for helping us open conversations and sometimes automate tests.”
She offered a user story: “As a customer, I want to withdraw money from an ATM, so that I don’t have to wait in line at the bank.”
Scenario 1:
- Given the debit card is valid; and given the account is in credit; and given the dispenser contains enough cash,
- When the customer requests cash,
- Then ensure the account is debited; and then ensure cash is dispensed; and then ensure the card is returned; and Then ensure a receipt is dispensed.
Given When Then is a good way to get started with BDD but Martin pointed out that it can be very long-winded with too many possibilities.
She argues that since there’s no data going into these GWT cases, it’s not specific enough yet to even be an example. It also doesn’t give priority to the most important inputs and outcomes.
This is why she says you should move forward from GWT to Specification by Example or SBE because it involves decision tables using real data values to set examples. SBE is said to reduce rework and clarify requirements from the start.
“Take input values to the system, execute something in the system, and then evaluate them against any expected results. You can express the givens and when and outputs and you can use this in a table of attributes,” Martin said.
What followed was an exercise any member of a business can do, mapping out the expected behavior of an ATM within a decision table called the OOPSI Model or OOPSI Mapping:
- Outcomes
- Outputs
- Process
- Scenarios
- Inputs
Martin co-wrote the OOPSI model as a way in to turn user stories into scenarios and tests. She used a table to add rationality to BDD user stories while removing duplication. She is arguing for OOPSI Mapping as a way to use Specification by Example around the tables of examples before turning them into features.
Like all things BDD, this can be first done using sticky notes and a whiteboard.
Following the same example exercise, start with Outcomes: As a customer, I want to withdraw cash so that I don’t have to wait in line at the bank.
“BDD is an outside-in practice, where you understand values, explore goals, and learning along the way,” Martin explained. Then, “starting with the Output helps us really understand what the value is and to have good conversations with business.”
Next, Outputs of the cash machine include:
- Cash
- Receipts, which may include balance
- Returned bank card
- Balance on screen
- An error message
Martin recommends illustrating Outputs with examples. In this situation, that may be a receipt or cash. Your OOPSI is something that is useful to share with your end users and concrete examples also help developers to understand data attributes.
You can often group Outputs, like getting the returned bank card, cash, and the receipt.
Now, imagine a Process for this:
- User enters card
- Machine checks card
- User enters PIN
- Machine checks PIN
- User chooses kind of account
- User requests cash
- Machine checks ATM balance
- Machine checks user’s balance
- Return card
- Dispense cash
- Dispense receipt
Next, based on this simple Process, what are the Scenarios? One follows.
Scenario 2: The customer has insufficient funds
- Given the debit card is valid; and Given the account is Not in credit; and Given the dispenser contains enough cash
- When the customer requests cash
- Then notify a rejection on screen; and Then return the card
But this is still shy of a specification driven by an example because Martin says the data is even more important than the words. Without data, Scenario 2 remains ambiguous.
There needs to be a table of Inputs and Preconditions, like the example below.
From your OOPSI model, you build tests that connect to each of these tables. It allows everyone to refer back to these tables to understand the rationale of the tests and the code that follows.
Martin pointed out that it also makes teams think of combinations of scenarios for common API pulls.
She offered final tips to finding success with Specification by Example:
- The whole team participates
- Customers/users participate
- It’s testable with real data
- Remove dependencies between tests
“You don’t want too many columns or too many Givens and Thens because it becomes unclear about what you’re testing — make smaller groups of tests and SBE tables,” Martin said.
You can then eliminate columns that are irrelevant for any particular scenario because the more OOPSI columns you have, the more complicated your planning is, which in turn means — more often than not — the more complicated your code is.
Behavior-driven design is so logical even a non-dev (like this author) can do it. It’s all about carefully mapping out the user journey, which you then turn into specifications and tests, which then turns into the code derived directly from the user journey.
Event Storming for BDD Chaos
Software Consultant Kenny Baas-Schwegler said behavior-driven design applies “Bounded context principles of consistent language, but [that] language is fluid, liquid, subject to change. Just someone entering your building will change the language.”
Baas-Schwegler believes a great way to engage teams around certain topics is by simply getting everybody — business, IT, and even key customers — in a room with a bunch of — you guessed it — sticky notes.
“We don’t understand each other so we need to try to create a model that creates understanding,” he said. “Stickies are easy to refactor — you just take off the board and throw them away.”
Baas-Schwegler continued that “It’s chaos. But that’s good because now we can have a meaningful conversation on the board.”
Event storming or model storming, built to collaborate above silos, is a timeline that flows from left to right, and is dedicated to quickly figuring out what is happening or should be happening at your software’s domain level.
As Mathias Verraes wrote, major motivations for Model Storming are:
- Discovering complexity early on, finding missing concepts, and understanding the business process
- Modeling or solving a specific problem in detail
- Learning how to model and think about modeling
Start by writing all the domain events on orange sticky notes. (Note: colors and their meanings change by team, but these follow these images.) Anything said is added to the board. After that chaos, ask participants to work in groups of at least five to organize them in logical process groupings. Explicitly name each process.
Next, add purple for the Givens. Then yellow for the Then variables, like if an order is above $20, it’s free delivery.
“If something I’m telling is not on the board, I write it on a sticky,” Baas-Schwegler said.
“We make it visible. We make it explicit. So our assumptions are lowered.”
Most of the time in BDD, any red Post-Its mean Stop, something is unclear and needs to be discussed immediately
But, in the end, Baas-Schwegler pointed out that you can never just have one tool because it leads to blind spots.
“A model is always wrong, so don’t cling to a mistake just because you spend a lot of time making it.” He said it’s all about using different models to get “our minds at the same levels so we don’t create the same assumptions.”
Feature image via Pixabay.
