How Can You Use TDD and BDD Methodologies Effectively to Build Agile Product Teams?
Test-driven development (TDD) and behaviour-driven development (BDD) are both highly popular methodologies, but there is confusion over what makes them different and when to use one vs the other.
As large enterprises build complex new platforms in the cloud using providers such AWS, Azure or GCP, the need to bridge the gap between what the business expects from these and what the technical experts (Developers, DevOps, Security, Testers) deliver has become critical to the success of large digital transformation initiatives.
With the push for Shift Left, Compliance as Code, approaches such as BDD are becoming more important in highly regulated environments.
In this blog, we will cover what makes TDD and BDD different, complimentary, why use them together and how to implement them as part of your agile software development.
What Is Test Driven Development (TDD)?
TDD is about writing tests first and then developing some code as opposed to software being developed first and test cases created later.
As Robin Lacey points out, TDD focuses on first writing failing tests to clearly delineate the function of a given piece of code and then writing the leanest amount of code possible to pass the test.
Next, developers follow a Red/Green/Refactor process. Specifically, that means:
- Design and write the failing test (Red)
- Develop just enough code that passes the test (Green)
- Refactor the code to make it the design clean as possible (Refactor)
- Repeat
Combined, this approach allows an incremental approach to the design of your software and as a side effect increases the tests coverage as well.
Building better designed software with TDD
A common misnomer is that TDD is focused on unit testing only. This is actually only part of the benefit of adopting this approach.
TDD is about how you design your software, from the perspective of its public interface. More importantly, TDD is about using tests to make sure the following qualities are embedded in your design:
- Easy to change
- Modular
- Cohesive
- Abstraction/information hiding
- Separation of concerns
- Loosely coupled
A common anti-pattern is that you can write Tests first, but end up with Software that actually breaks these principals. The result, poorly written tests that reflect poorly designed software.
Therefore, as a guiding principle you should build your software using TDD in increments and verify if it is loosely coupled, easy to change, cohesive, and promotes separation of concerns.
What Is Behaviour-Driven Development (BDD)?
BDD expands the discussion and focuses on building a shared understanding/agreement with key stakeholders on how the application should behave. These stakeholders include developers, testers, product owners and the actual users.
You understand the customer problem and desired outcomes first before writing any code. BDD is more about specification of the behaviour of your system, rather than what automated tests you need to write.
As Carlos Nunez pointed out, BDD provides a continuous interface through which product teams and engineers can collaborate and iterate on feature development.
You use plain language to describe a customer scenario. It is important for the team to agree on the format and make this a requirement in the DoR. In doing so, you provide a consistent and repeatable approach that will provide what the developer needs in order to design the test.
While not required and to provide an example, typically teams use the following format:
Narrative
As a [who]
I want [what]
So that [why]
Acceptance Criteria:
Given [context] (prerequisites)
When [event] (action)
Then [outcome] (expected)
The key distinction is to describe business behaviour without defining implementation. A common trap for teams is to start solutionising during refinement. The outcome of refinement is to define the problem and have agreement on what success looks like, just avoid discussing how many hours it will take.
TDD vs BDD: What’s the Difference?
BDD is an extension of TDD, and clearly enables you to define system behaviour as defined by the business in a common ubiquitous language.
When you practise BDD, you are in effect practising the TDD process. Each has different goals:
- TDD allows incremental development
- TDD aids at improving the design of your software components
- BDD shared understanding and alignment with key stakeholders
In short, TDD is about designing tests first, writing enough code to pass the test, then following a Red-Green-Refactor loop until the developer feels enough functionality exists to satisfy the acceptance criteria.
BDD means building a shared understanding/agreement with a wider group of stakeholders using plain human readable language to describe how the code/application needs to behave.
TDD is a competency to build in your developers, while BDD is a competency to build in your product owners. Together it is a collective team effort. For each to succeed, they need the other.
Why Use TDD and BDD Together?
When used together, developers will find it easier to link their TDD tests with the BDD plain language. You continuously reinforce this behaviour as long as the acceptance criteria is set up in advance to clearly define the customer problem and desired outcomes. There are tools out there that will help you make this process permanent.
A key indicator of success will be ensuring that the product owner/developer create three files consistently:
- The scenario (feature) file describing in plain text the acceptance criteria (BDD/PO).
- The unit test file describes how to test components separately and how they interact (TDD/developer).
- The actual code file(s)(eveloper/Python/Java)
Having this in place will help the developers to 'keep doing TDD'. Meaning TDD/BDD is as much a people and process competency as a technical competency.
How To Make a Winning Business Case for the Cloud
Sold on the cloud? Here’s the next step.
Securing buy-in for your move to the cloud takes more than just enthusiasm and conversations. To make sure you're prepared for all the meetings, presentations, documents and approvals, you'll need a really compelling business case.
Read our eBook to find out how to:
- Focus on the business outcome
- Find your why
- Frame the problem
- Adopt an experimental, data-driven approach
Extending the Value of BDD to Platform Engineering
Applying BDD correctly should help establish strong communication feedback loops between technical experts and domain experts (business analysts or product wwners). However, BDD is not just limited to software development scenarios.
As more companies build platforms using public cloud, with emerging trends such as platform engineering, the need to communicate the value of platforms to the business has become crucial.
A typical gap, and common challenge is in highly regulated environments such as financial services. Misalignment between domain experts requirements and technical teams can lead to platforms and systems that don’t meet the expectations of the key stakeholders.
By adopting techniques such as BDD and using domain-specific languages to describe the behaviour of your development and production environments, your DevOps or platform engineering team can reap the benefits of:
- Create executable specifications which communicate clearly with agreed requirements and acceptance criteria
- Automate the acceptance of environments using BDD test automation frameworks
- Easy to understand DSL specifications for numerous stakeholders such as security teams
- Tools such as Pester (PowerShell) and terraform compliance enable DevOps/Platform engineering teams to use BDD DSL to describe the behaviour of their infrastructure
Summary
To summarise, by adopting BDD and TDD practices, the team should be able to build better quality software. Communication with the business should improve by driving features through the language of specifying the key scenarios the software must satisfy. This amplifies the feedback loop between those who are experts in implementation (developers) and domain experts (business).
Working with BDD in tandem, you can demonstrate delivery of business value through using automated BDD test frameworks. It provides a living documentation of executable specifications that demonstrate how each feature meets the business requirements.
Additionally, by building on top of these software practises, the team should see an improvement in following metrics as defined by DORA:
- Deployment Frequency—How often an organisation successfully releases to production
- Lead Time for Changes—The amount of time it takes a commit to get into production
- Change Failure Rate—The percentage of deployments causing a failure in production
- Time to Restore Service—How long it takes an organisation to recover from a failure in production
BDD and TDD are essential tools for building quality into your systems and ensuring your business goals are met.
