Behaviour Driven Development, or BDD, is a software development methodology that has gained significant traction in recent years. What is BDD, where did it come from and what does it offer the test team?
Test Driven Development
BDD evolved from Test Driven Development. Test Driven Development (TDD) is a development process where you write the tests for the desired output of your code before writing the actual code itself. This helps to ensure that the code will work as expected and any bugs are caught early on.
The process involves writing a test, running the test, and then writing code to make the test pass. This helps developers to break down the problem into smaller chunks that are easier to manage. It also makes debugging much simpler since you can quickly pinpoint where errors arise.
TDD however is primarily a development practice executed by the developer to create a well written block of code that performs a set of functions correctly.
This very modularity can isolate the developer from the overall goals of the project. The code works correctly but not necessarily satisfies the needs and expectations of the end user.
Behaviour Driven Development
This led to the creation of behaviour driven development (BDD). BDD puts a greater emphasis on building a shared understanding of the expected behaviour of a software product between developers, software quality assurance practitioners and the customer that will use the software. This helps ensure that the business expectation and user experience is at the forefront of design decisions. This is the so-called outside-in approach.
BDD was first developed by Dan North in 2006. North believed that most software projects failed due to a lack of communication between stakeholders. He wanted to create a process that would make it easier for teams to collaborate and build better software. To that end, BDD helps teams articulate the behaviour of their systems in plain language and share it with stakeholders outside the development team.
BDD draws on the Agile Framework concept of “user stories”. This is an informal, natural language description of how a software product should work and what it’s outcomes should be. Typically, BDD makes use of a domain specific language such as Gherkin to define test cases sufficient for a developer to work with but in language plain enough to be read by non-technical users.
It is usual that a Given-When-Then structure is used: Given describes the initial state of the system; When describes the actions undertaken by the user; and Then explains what the outcome of that action should be. Tools such as Cucumber and Selenium can take this plain text and generate a code framework ready to be built upon. This process is iterated as the development proceeds.
Pros & Cons
BDD does have its disadvantages. It is time and effort intensive. It requires a large amount of work to develop scenarios that are clear, concise, and readily workable. BDD is also heavily dependent on the relationships between stakeholders and developers. This is both at the planning stage and the development stage where a disconnect can make it difficult to resolve ambiguities.
Conversely when the collaboration dynamic works well it can engage all the parties involved in the project with the development process. This leads to greater clarity in what the customer actually requires from the software. This clarity enables the developers to progress with confidence that they are achieving what the client wants. The domain specific language of the specification of scenarios are readily converted to automated test steps. The modular design makes adaptation easier to achieve.
Most importantly BDD enforces a quality first approach across the whole project which is maximally beneficial to everyone involved.
