PEARL X : Behavior Driven Development provides stakeholder value through collaboration throughout the entire project
Behavior-driven development was developed by Dan North as a response to the issues encountered teaching test-driven development:
- Where to start in the process
- What to test and what not to test
- How much to test in one go
- What to call the tests
- How to understand why a test fails
At its core, behavior-driven development is a specialized version of test-driven development which focuses on behavioral specification of software units.
Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:
- define a test set for the unit first;
- then implement the unit;
- finally verify that the implementation of the unit makes the tests succeed.
This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. The original developer of BDD (Dan North) came up with the notion of BDD because he was dissatisfied with the lack of any specification within TDD of what should be tested and how. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.
Behavior Driven Development
Behavior-driven development specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit. Borrowing from agile software development the “desired behavior” in this case consists of the requirements set by the business — that is, the desired behavior that has business value for whatever entity commissioned the software unit under construction. Within BDD practice, this is referred to as BDD being an “outside-in” activity.
BDD practices
The practices of BDD include:
- Establishing the goals of different stakeholders required for a vision to be implemented
- Drawing out features which will achieve those goals using feature injection
- Involving stakeholders in the implementation process through outside–in software development
- Using examples to describe the behavior of the application, or of units of code
- Automating those examples to provide quick feedback and regression testing
- Using ‘should’ when describing the behavior of software to help clarify responsibility and allow the software’s functionality to be questioned
- Using ‘ensure’ when describing responsibilities of software to differentiate outcomes in the scope of the code in question from side-effects of other elements of code.
- Using mocks to stand-in for collaborating modules of code which have not yet been written
Domain-Driven Design (DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can lead to software abstractions called domain models. These models encapsulate complex business logic, closing the gap between business reality and code.
Outside–in
BDD is driven by business value; that is, the benefit to the business which accrues once the application is in production. The only way in which this benefit can be realized is through the user interface(s) to the application, usually (but not always) a GUI.
In the same way, each piece of code, starting with the UI, can be considered a stakeholder of the other modules of code which it uses. Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.
The first piece of production code that BDD developers implement is the UI. Developers can then benefit from quick feedback as to whether the UI looks and behaves appropriately. Through code, and using principles of good design and refactoring, developers discover collaborators of the UI, and of every unit of code thereafter. This helps them adhere to the principle of YAGNI, since each piece of production code is required either by the business, or by another piece of code already written.
YAGNI : You Are Not Goingto Need It
User stories are the central axis around which a software project rotates. Developers use user stories to capture requirements and to express customer expectations. User stories provide the unit of effort that project management uses to plan and to track progress. Estimations are made against user stories, and user stories are where software design begins. User stories help to shape a system’s usability and user experience.
User stories express requirements in terms of The Role, The Goal, and The Motivation.
A BDD story is written by the whole team and used as both requirements and executable test cases. It is a way to perform test-driven development (TDD) with a clarity that cannot be accomplished with unit testing. It is a way to describe and test functionality in (almost) natural language.
BDD Story Format
Even though there are different variations of the BDD story template, they all have two common elements: narrative and scenario. Each narrative is followed by one or more scenarios.
The BDD story format looks like this:
Narrative:
In order to [benefit]
As a [role]
I want to [feature]
Scenario: [description]
Given [context or precondition]
When [event or action]
Then [outcome validation]
“User stories are a promise for a conversation” (Ron Jeffries)
A BDD story consists of a narrative and one or more scenarios. A narrative is a short, simple description of a feature told from the perspective of a person or role that requires the new functionality. The intention of the narrative is NOT to provide a complete description of what is to be developed but to provide a basis for communication between all interested parties (business, analysts, developers, testers, etc.) The narrative shifts the focus from writing features to discussing them.
Even though it is usually very short, it tries to answer three basic questions that are often overlooked in traditional requirements.
What is the benefit or value that should be produced (In order to)?
Who needs it (As a)? And what is a feature or goal (I want to)?
With those questions answered, the team can start defining the best solution in collaboration with the stakeholders.
The narrative is further defined through scenarios that provide a definition of done, and acceptance criteria that confirm that narrative that was developed fulfill expectations.
It is important to remember that the written part of a BDD story is incomplete until discussions about that narrative occur and scenarios are written. Only the whole story (narrative and one or more scenarios) represents a full description of the functionality and definition of done.
If more information is needed, narratives can point to a diagram, workflow, spreadsheet, or any other external document.
Since narratives have some characteristics of traditional requirements, it is important to describe distinctions. Two most important differences are precision and planning
Precision
Narratives favor verbal communication. Written language is very imprecise, and team members and stakeholders might interpret the requirement in a different way.
Verbal communication wins over written.
As another example, is the following requirement statement relating to a registration screen: “The system shall allow the user to register using 16 character username and 8 character password”.
It was unclear whether the username MUST be 16 characters or whether it could be any length up to 16 characters, or whether it could be any length with a minimum of 16 characters. In this particular case, the business analyst removed any doubt as soon as clarification was asked.
However, there are many other cases
when developers take requirements as a final product and simply implement them in a way they understand them. In those cases they might not understand the reasons behind those requirements but just “follow specifications”. They might have a better solution in mind that never gets discussed.
Planning
IEEE 830 style requirements (“The system shall…”) often consist of hundreds or even thousands of statements. Planning such a large number of statements is extremely difficult. There are too many of them to be prioritized and estimated, and it is hard to understand which functionalities should be developed. That is especially evident when those statements are separated into different sections that represent different parts of the system or products. Without adequate prioritization, estimation, and description of the functionality itself, it is very hard to accomplish an iterative and incremental development process. Even if there is some kind of iteration plan, it can take a long time for a completed functionality to be delivered, since the development of isolated parts of the
system is done in a different order and at a different speed.
Narratives are not requirement statements
The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications. This document is known as IEEE Standard 830 and it was last updated in 1998. One of the
characteristics of an IEEE 830 statement is the use of the phrase
“The system shall…”. Examples would be:
The system shall allow the user to login using a username and password.
The system shall have a login confirmation screen.
The system shall allow 3 unsuccessful login attempts.
Writing requirements in this way has many disadvantages: it is error prone and time-consuming, to name but two. Two other important disadvantages are that it is boring and too long to read.
This might seem irrelevant until you realize the implications. If reviewers and, if there is such a process, those who need to sign off requirements do NOT read it thoroughly and skip sections out of boredom, or because it does NOT affect them, many things will be missed. Moreover, having a big document written at that level often prevents readers from understanding the big picture and the real goal of the project.
A Waterfall model combined with IEEE 830 requirements tends to plan everything in advance, define all details, and hope that the project execution will be flawless. In reality, there are almost no successful software projects that manage to accomplish these goals. Requirements change over time resulting in “change requests”. Changes are unavoidable and only through constant communication and short iterations can the team reduce the impact of these changes. IEEE 830 statements are a big document in the form of a checklist. Written, done, forgotten, the overall understanding is lost. The need for constant reevaluation is nonexistent.
Consider the following requirements:
- The product shall have 4 wheels.
- The product shall have a steering wheel.
- The product shall be powered by electricity.
- The product shall be produced in different colors.
Each of those statements can be developed and tested independently and assembled at the end of the process. The first image in someone’s head might be an electrically-powered car.
That image is incorrect. It is a car, it has four wheels, it is powered by electricity (rechargeable batteries) and it can be purchased in different colors. it is A toy car
That is probably not what individual would think from reading those statements. A better description would be:
Narrative:
In order to provide entertainment for children
As a parent
I want a small-sized car
By looking at this narrative, it is clear what the purpose is (enter- tainment for children), who needs it (parents), and what it is (a small-sized car). It does not provide all the details since the main purpose is to establish the communication that will result in more information and understanding of someone’s needs.
That process might end with one narrative being split into many. Further on, scenarios produced from that narrative act as acceptance criteria, tests, and definition of done.
Who can write narratives?
Anyone can write narratives. Teams that are switching to Agile tend to have business analysts as writers and owners of narratives or even whole BDD stories (a narrative with one or more scenarios).
In more mature agile teams, the product owner has a responsibility to make sure that there is a product backlog with BDD stories. That does not mean that he writes them. Each member of the team can write BDD stories or parts of them (narrative or scenario).
Whether all the narratives are written by one person (customer, business analyst, or product owner) or anyone can write them (developers, testers, etc.) usually depends on the type of organization and customers. Organizations that are used to “traditional” requirements and procedures that require them to have those requirements “signed” before the project starts often struggle during their transition to Agile and iterative development. In cases like this, having one person (usually a business analyst) as the owner and writer of narratives might make a smoother transition towards team ownership and lower the impact on the organization
A good BDD narrative uses the “INVEST” model:
- Independent. Reduced dependencies = easier to plan.
- Negotiable. Details added via collaboration.
- Valuable. Provides value to the customer.
- Estimable. Too big or too vague = not estimable.
- Small. Can be done in less than a week by the team.
- Testable. Good acceptance criteria defined as scenarios.
While IEEE 830 requirements are focused on system operations, BDD narratives focus on customer value. They encourage looseness of information in order to foster a higher level of collaboration between stakeholders and the team. The actual work being done is accomplished through collaboration revolving around the narrative that becomes more detailed through scenarios as the development progresses. Narratives are at higher level than IEEE 830 requirements. Narratives are followed by collaboratively developed scenarios which define when the BDD story meets the expectations.
Scenarios
Even though narratives can be written by anyone, it is often the result of conversations between the product owner or business analyst and the business stakeholder.
Scenarios describe interactions between user roles and the system. They are written in plain language with minimal technical details so that all stakeholders (customer, developers, testers, designers, marketing managers, etc.) can have a common base for use in discussions, development, and testing.
Scenarios are the acceptance criteria of the narrative. They represent the definition of done. Once all scenarios have been implemented, the story is considered finished. Scenarios can be written by anyone, with testers leading the effort.
The whole process should be iterative within the sprint; as the development of the BDD story progresses, new scenarios can be written to cover cases not thought of before. The initial set of scenarios should cover the “happy path”. Alternative paths should be added progressively during the duration of the sprint.
Format
Scenarios consist of a description and given, when, and then steps.
The scenario description is a short explanation of what the scenario does. It should be possible to understand the scenario from its description. It should not contain details and should not be longer than ten words.
Steps are a sequence of preconditions, events, and outcomes of a scenario. Each step must start with words given, when or then.
The Given step describes the context or precondition that needs to be fulfilled.
Given visitor is on the home screen
The When step describes an action or some event.
When user logs in
The Then step describes an outcome.
Then welcome message is displayed
Any number of given, when and then steps can be combined, but at least one of each must be present. BDD steps increase the quality of conversations by forcing participants to think in terms of pre-conditions that allow users to perform actions that result in some outcomes. By using those three types of steps, the quality of the interactions between team members and stakeholders increases.
Process
The following process should be followed.
1. Write and discuss narrative.
2. Write and discuss short descriptions of scenarios.
3. Write steps for each scenario.
4. Repeat steps 2 and 3 during the development of the
narrative.
By starting only with scenario descriptions, we are creating a basis that will be further developed through steps. It allows us to discuss different aspects of the narrative without going into the details of all the steps required for each of the scenarios. Do not spend too much time writing descriptions of all possible scenarios. New ones will be written later.
Once each scenario has been fully written (description and steps) new possibilities and combinations will be discovered, resulting in more scenarios.
Each action or set of actions (when steps) is followed by one or more outcomes (then steps). Even though this scenario provides a solid base, several steps are still missing. This situation is fairly common because many steps are not obvious from the start.
Additional preconditions, actions, and outcomes become apparent only after first version of the scenario has been written.
This scenario covers one of many different combinations. It describes the “happy path” where all actions have been performed successfully. To specify alternative paths, we can
copy this scenario and modify it a bit.
This scenario was not written and fully perfected at the first attempt but through several iterations. With each version of the scenario, new questions were asked and new possibilities were explored.
The process of writing one scenario can take several days or even weeks. It can be done in parallel with code development. As soon as the first version of the scenario has been completed, development can start. As development progresses, unexpected situations will arise and will need to be reflected in scenarios.
Behavior-driven development borrows the concept of the ubiquitous language from domain driven design. A ubiquitous language is a (semi-)formal language that is shared by all members of a software development team — both software developers and non-technical personnel. The language in question is both used and developed by all team members as a common means of discussing the domain of the software in question. In this way BDD becomes a vehicle for communication between all the different roles in a software project.
BDD uses the specification of desired behavior as a ubiquitous language for the project team members. This is the reason that BDD insists on a semi-formal language for behavioral specification: some formality is a requirement for being a ubiquitous language. In addition, having such a ubiquitous language creates a domain model of specifications, so that specifications may be reasoned about formally. This model is also the basis for the different BDD-supporting software tools that are available.
Much like test-driven design practice, behavior-driven development assumes the use of specialized support tooling in a project. Inasmuch as BDD is, in many respects, a more specific version of TDD, the tooling for BDD is similar to that for TDD, but makes more demands on the developer than basic TDD tooling.
Tooling principles
In principle a BDD support tool is a testing framework for software, much like the tools that support TDD. However, where TDD tools tend to be quite free-format in what is allowed for specifying tests, BDD tools are linked to the definition of the ubiquitous language discussed earlier.
As discussed, the ubiquitous language allows business analysts to write down behavioral requirements in a way that will also be understood by developers. The principle of BDD support tooling is to make these same requirements documents directly executable as a collection of tests. The exact implementation of this varies per tool, but agile practice has come up with the following general process:
- The tooling reads a specification document.
- The tooling directly understands completely formal parts of the ubiquitous language . Based on this, the tool breaks each scenario up into meaningful clauses.
- Each individual clause in a scenario is transformed into some sort of parameter for a test for the user story. This part requires project-specific work by the software developers.
- The framework then executes the test for each scenario, with the parameters from that scenario.
Dan North has developed a number of frameworks that support BDD (including JBehave and RBehave), whose operation is based on the template that he suggested for recording user stories These tools use a textual description for use cases and several other tools (such as CBehave) have followed suit. However, this format is not required and so there are other tools that use other formats as well. For example Fitnesse (which is built around decision tables), has also been used to roll out BDD.
Tooling examples
There are several different examples of BDD software tools in use in projects today, for different platforms and programming languages.
Possibly the most well-known is JBehave, which was developed by Dan North. The following is an example taken from that project:
Consider an implementation of the Game of Life. A domain expert (or business analyst) might want to specify what should happen when someone is setting up a starting configuration of the game grid. To do this, he might want to give an example of a number of steps taken by a person who is toggling cells. Skipping over the narrative part, he might do this by writing up the following scenario into a plain text document (which is the type of input document that JBehave reads):
Given a 5 by 5 game When I toggle the cell at (3, 2) Then the grid should look like ..... ..... ..... ..X.. ..... When I toggle the cell at (3, 1) Then the grid should look like ..... ..... ..... ..X.. ..X.. When I toggle the cell at (3, 2) Then the grid should look like ..... ..... ..... ..... ..X..
The bold print is not actually part of the input; it is included here to show which words are recognized as formal language. JBehave recognizes the terms Given (as a precondition which defines the start of a scenario), When (as an event trigger) and Then (as a postcondition which must be verified as the outcome of the action that follows the trigger). Based on this, JBehave is capable of reading the text file containing the scenario and parsing it into clauses (a set-up clause and then three event triggers with verifiable conditions). JBehave then takes these clauses and passes them on to code that is capable of setting a test, responding to the event triggers and verifying the outcome. This code must be written by the developers in the project team (in Java, because that is the platform JBehave is based on). In this case, the code might look like this:
private Game game; private StringRenderer renderer; @Given("a $width by $height game") public void theGameIsRunning(int width, int height) { game = new Game(width, height); renderer = new StringRenderer(); game.setObserver(renderer); } @When("I toggle the cell at ($column, $row)") public void iToggleTheCellAt(int column, int row) { game.toggleCellAt(column, row); } @Then("the grid should look like $grid") public void theGridShouldLookLike(String grid) { assertThat(renderer.asString(), equalTo(grid)); }
The code has a method for every type of clause in a scenario. JBehave will identify which method goes with which clause through the use of annotations and will call each method in order while running through the scenario. The text in each clause in the scenario is expected to match the template text given in the code for that clause (for example, a Given in a scenario is expected to be followed by a clause of the form “a X by Y game”). JBehave supports the matching of actual clauses to templates and has built-in support for picking terms out of the template and passing them to methods in the test code as parameters. The test code provides an implementation for each clause type in a scenario which interacts with the code that is being tested and performs an actual test based on the scenario. In this case:
- The
theGameIsRunningmethod reacts to a Given clause by setting up the initial game grid. - The
iToggleTheCellAtmethod reacts to a When clause by firing off the toggle event described in the clause. - The
theGridShouldLookLikemethod reacts to a Then clause by comparing the actual state of the game grid to the expected state from the scenario.
The primary function of this code is to be a bridge between a text file with a story and the actual code being tested. Note that the test code has access to the code being tested (in this case an instance of Game) and is very simple in nature (has to be, otherwise a developer would end up having to write tests for his tests).
Finally, in order to run the tests, JBehave requires some plumbing code that identifies the text files which contain scenarios and which inject dependencies (like instances of Game) into the test code. This plumbing code is not illustrated here, since it is a technical requirement of JBehave and does not relate directly to the principle of BDD-style testing.
Story versus specification
A separate subcategory of behavior-driven development is formed by tools that use specifications as an input language rather than user stories. An example of this style is the RSpec tool that was also developed by Dan North. Specification tools don’t use user stories as an input format for test scenarios but rather use functional specifications for units that are being tested. These specifications often have a more technical nature than user stories and are usually less convenient for communication with business personnel than are user stories. An example of a specification for a stack might look like this:
Specification: Stack When a new stack is created Then it is empty When an element is added to the stack Then that element is at the top of the stack When a stack has N elements And element E is on top of the stack Then a pop operation returns E And the new size of the stack is N-1
Such a specification may exactly specify the behavior of the component being tested, but is less meaningful to a business user. As a result, specification-based testing is seen in BDD practice as a complement to story-based testing and operates at a lower level. Specification testing is often seen as a replacement for free-format unit testing.
Specification testing tools like RSpec and JDave are somewhat different in nature from tools like JBehave. Since they are seen as alternatives to basic unit testing tools like JUnit, these tools tend to favor forgoing the separation of story and testing code and prefer embedding the specification directly in the test code instead. For example, an RSpec test for a hashtable might look like this:
describe Hash do before(:each) do @hash = Hash.new(:hello => 'world') end it "should return a blank instance" do Hash.new.should eql({}) end it "should hash the correct information in a key" do @hash[:hello].should eql('world') end end
This example shows a specification in readable language embedded in executable code. In this case a choice of the tool is to formalize the specification language into the language of the test code by adding methods named it and should. Also there is the concept of a specification precondition – the before section establishes the preconditions that the specification is based on.
Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid – all rolled into one format.
Cucumber works with Ruby, Java, .NET, Flex or web applications written in any language. It has been translated to over 40 spoken languages.
Cucumber also supports more succinct tests in tables – similar to what FIT does. Users can view the examples and documentation to learn more about Cucumber tables.
Gherkin gives us a lightweight structure for documenting examples of the behavior our stakeholders want, in a way that it can be easily understood both by the stakeholders and by Cucumber. Although we can call Gherkin a programming language, its primary design goal is human readability, meaning you can write automated tests that read like documentation.
Using mocks
BDD proponents claim that the use of “should” and “ensureThat” in BDD examples encourages developers to question whether the responsibilities they’re assigning to their classes are appropriate, or whether they can be delegated or moved to another class entirely. Practitioners use an object which is simpler than the collaborating code, and provides the same interface but more predictable behavior. This is injected into the code which needs it, and examples of that code’s behavior are written using this object instead of the production version.
These objects can either be created by hand, or created using a mocking framework such as mock.
Questioning responsibilities in this way, and using mocks to fulfill the required roles of collaborating classes, encourages the use of Role-based Interfaces. It also helps to keep the classes small and loosely coupled.
Pearls of Wisdom 