Lucia Cavero-Baptista
In a traditional software development process, developers write programs and build features, and testers then test the written pieces of software. However, businesses are now operating at a faster pace and, therefore, software development needs to keep up with business demands.
In order to guarantee software quality at this development rhythm, the traditional software development process has shifted towards more Agile methodologies. One of these is Behavior-driven development (BDD).
What is Behavior Driven Development?
Behavior-driven development (BDD) is a methodology in Agile software development that aims to narrow the communication gaps between team members. In this method, the collaboration between developers, QA and non-technical or business analysts in a software project is encouraged. It encourages teams to use conversation and real-world examples to foster a better and shared understanding of how the application should behave.
The Behavior Driven Development process
It emerged from test-driven development (TDD), where tests are written before code and passing the tests is the critical driver of software development. BDD makes use of the general techniques and principles of TDD while providing all relevant teams with a shared process to collaborate on software development.
This shared process is facilitated through the use of a simple domain-specific language (DSL) using normal language constructs, such as English-like sentences, that express the behavior and expected outcomes.
Behavior Driven Development and Test Automation
Behavior-driven development makes us rethink our approach towards unit testing and acceptance testing so that we avoid issues that naturally arise.
Unit tests should be specified in terms of the desired behavior of the unit, that is the requirements set by the business. By specifying these terms in advance, we make sure that developers won't have to revisit work because requirements were misunderstood.
In BBD, unit test names are whole sentences starting with a conditional verb – "should" – written in order of business value. At the very beginning of a feature file, we write acceptance tests using the standard agile framework of a user story:
- As a [role]
- I want [feature]
- So that [benefit]
Once the feature file has been established and agreed by the business participants, we then write the acceptance criteria to test that behavior. The acceptance criteria for a feature is written in terms of scenarios and implemented as classes. This allows for regular expressions – DSL – to map steps in a feature file to concrete actions. A scenario is written in the following format:
- Given [initial context]
- When [event occurs]
- Then [ensure outcome]
- And/But [more outcomes if applicable]
BBD allows for easy test automation. The suite of unit tests is continuously providing feedback to ensure that each key component is still working. The unit tests act as evergreen documentation so, in a way, the test suites also function as a regression safety net on bugs.
Key Takeaways
- BDD is a collaborative method that requires a cross-functional team consisting of customer/client, BAs, QAs, testers, UI & UX designers and software developers.
- It is an outside-in activity, meaning that the entity that has commissioned the software unit under construction ensures control over the "desired behavior".
- It uses domain-specific language (DSL) that can be easily read and understood by everyone.
- Test cases clearly articulate what we need our code to do.
- It forces critical analysis and design since the developer needs to fully understand the desired result product and how to test it before developing the production code. This, in turn, reduces the overhead caused by common developer hurdles.
By using BDD as a form of test automation, companies can streamline activities in software development.
Whether you want to avoid technical time waste caused by a reluctance to refactor code, slow feedback caused by handovers and silos, or rework caused by vague requirements, BDD offers a pro-active approach to software development.
BDD is a way of working that applies in both development, as described in the above example above using unit testing, and also in QA.
Learn more about BDD in the whitepaper:
