The first action in every project is the conversation about the behavior of the features or software to be built. A businessperson or client comes to the development team and explains what he wants. The discussions can happen in the form of a user story or design documents or flowcharts, or mock-ups, or sometimes hurried phone calls. From this interaction alone, the development team needs to construct the project that just works.
However, how do they test this shared capital and the list of system behaviors? This is where BDD (Behavior-driven development) appears.
What is BDD?
BDD is a framework that is a logical next step from TDD i.e. Test-Driven Development, the most commonly used testing terminology. Dan North has developed, defined & created the BDD framework in the year 2003. BDD offers an efficient approach in the Agile Software Development process, where all the stakeholders work collaboratively to define a set of high-level task specifications during the analysis phase of development.
It involves the active participation of the technical team (involving developers, testers, architects, scrum masters, analysts, etc.) as well as business personnel. With BDD, you can determine the clearest overview of actual business requirements within the application. And, analyze the requirements with an effective & efficient conversation with the respective stakeholders. It allows the technical team to focus on the coding process and writing business logic itself, rather than investing time in understanding assumptions about the behavior of certain process flow.
Interested reader can read Agile testing vs traditional testing
BDD Specifications
In practice, the approach of BDD looks like this:
Image source: adoriasoft.com
The approach includes the following steps:
- Identify the scenario for the given business feature
- Define steps for the scenario
- Run the scenario and if fails
- Write code to pass the scenario
- Refactor the code, build a reusable automation library
- Run the scenario and pass
Business features, scenarios & steps together make Behavior tests. This test is generally written in a business readable DSL (domain-specific language) by BA (Business Analysts).
BDD mainly focuses on
- Where to begin in the process
- Areas to include/exclude from testing
- Amount of testing to be done in a single operation
- Threshold points where the test fails
Principles of BDD
In the TDD software development process, each section/functionality of software development is distributed into respective units. And each unit must adhere to the following criteria:
- Define test cases for unit testing
- Process execution to fail the tests
- Implement & integrate the unit
- Test, verify & confirm whether the implementation of the unit processes to be a success.
This TDD definition allows tests in terms of low technical details and a high level of software requirement or something in between. However, BDD makes more specific picks than TDD. It combines the TDD principles and insists that tests of any software units should be mentioned concerning its desired behavior. The desired behavior includes needs set by the business like the behavior, which possesses business value for a given entity.
Behavioral Specifications
Similar to Object-Oriented Analysis and Design (OOAD) terminology user story, BDD uses behavioral specifications as a semi-informal way to define development scenarios.
BDD specifies that business process analysts and software developers should function collaboratively. And, they should document behavior in terms of user specifications in descriptive form just like user stories in Agile Scrum Methodology. This document is composed in a specific format.
Here is the format structure of Behavioral Specifications:
Title
A title to describe the specifications
Narrative
A short introduction about the section following the pre-defined structure:
- As a: an individual actor who will benefit from the feature
- I want: the feature or list of features
- so that: expected outcome to receive benefit from the feature
Acceptance criteria
An explanation of each specific scenario of the narrative with the following structure:
- Given: the initial state or background story to give an insight into the scenario, in one or more clauses
- When: The event that triggers the scenario
- Then: the expected outcome, as per clauses specified in the above steps
Features of the BDD approach
Ubiquitous language
- Ubiquitous language associated with BDD is easy to understand and interpret
- This simply avoids any amount of confusion or misconception regarding any terminology used while constructing a scenario.
Abstract and precise process flow
- Specifications documented are abstract and precise, thus unambiguous steps and approaches towards development are avoided or very minimum.
Collaborative approach
- As this process ensures collaboration of technical & business development and relevant teams, the project requirements and understandings are much clear and at an optimum level at times.
- Project requirements are directly served from users or business holders, thus the user behavior becomes the most focused area.
Ease of programming
- Test, Verify & Confirm approach enables users to focus more on business logic, thus optimized and the well-structured product would be developed.
- Debugging process is also much simpler than normal development approach.
- Software delivery time also comparatively reduced.
Low-cost factor
- As BDD leads to a higher quality of code, there is a minimum level of project maintenance cost.
Wrapping up
BDD is a behavioral oriented agile-based development methodology. It focuses on gaining requirements by understanding the behavior of the proposed software by communicating with associated stakeholders. Thus, developers precisely focus on code and coding constraints and not much stress on technical aspects.
