Understanding TDD Vs BDD and How You Can Use Both to Transform Into an Agile Product Team
Test-driven development (TDD) and behavior-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.
In this blog, we will cover what makes TDD and BDD different, complimentary, why use them together and how to implement them for those making the transition from a project to a product team.
But first, we need to understand how this all fits into the Agile framework...
How to Use Agile to Set Your Team up for Success
In many IT organizations, some projects start with temporary contractors creating a new solution for an immediate need. Once complete, the project either ends or emerges into a continual project with different people joining and/or leaving. This creates the problem of knowledge management and transfer within the team. The business quickly realizes the need for a permanent product team that can improve the solution over time and based on real user feedback.
In Agile, you don’t need all the answers at the beginning, you learn as you go and this feedback helps developers create functionality people actually need and use.
With this context, the team evolves and typically a Product Owner (PO) role emerges. The collective team relies on the PO to capture the external requests and feedback from the real users (referred to as the client). The PO will maintain a short term backlog of two sprints worth of refined work and also manages the long term roadmap that looks at the next six months. This is combined with the internal needs of the team to pay down tech debt and/or optimization efforts.
If you take an engineering first approach, you can see how this fits into Agile development:
The following basics of engineering align with TDD/BDD and the team:
- Define the business problem (BDD)
- Define the technical problem to solve the business problem (BDD/TDD)
- Design a technical solution to solve the technical problem (TDD)
- Test and validate (TDD)
- Verify technical solution solves technical problem (Demo/PO acceptance)
- Verify technical problem solves business problem (Demo/Stakeholder acceptance)
- Done else redesign/refactor
With this in place, the team has a solid foundation to apply testing strategies within Agile.
This is why it is important Agile teams build an internal agreement around Definition of Ready (DoR) and Definition of Done (DoD) prior to starting any work. This helps to define and not move the goal posts.
The sign of a healthy product team is where they meet prior to the sprint commencement and define good acceptance criteria for each user story and how those user stories map into a larger feature.
The idea is to add value in multiple iterations. Smaller changes faster provides better feedback and the ability to learn based on experimentation.
What Is Test Driven Development (TDD)?
TDD is about designing tests first and then coding 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 slither 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 as clean as possible (Refactor)
- Repeat
Initially this will feel slower. However, developers who adapt this process feel more confident in their code. This removes a lot of uncertainty and helps build velocity over time. As time passes, the code test coverage grows. TDD forces that all tests pass as the code changes. This regression testing ensures you catch any breaking changes as you add new capability.
Combined, this approach will reduce your change failure rate. You can make the case in order to go fast, you have to go slow.
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.
As Carlos Nunez pointed out, BDD provides a continuous interface through which product teams and engineering 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 behavior without defining implementation. A common trap for teams is to start solutioning 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. When you practice BDD, you are in effect practicing the TDD process. Each has different goals:
- TDD - allows incremental development
- 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 behavior 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 PO/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) (Developer/Python/Java)
Having this in place will help the Developers to 'keep doing TDD'. Meaning TDD/BDD is as much a people/process competency as a technical competency.
Top 20 Digital Transformation Innovators: Europe 2021
What are the secrets to a successful digital transformation?
Hear from the experts at O2, The Football Association, Nationwide, Sainsbury's, Credit Suisse, Transport for London, Government Digital Service, Ocado, BNP Paribas and more!
How to Build a Product Delivery Team
What next?
Entry point for building a product delivery team can start anywhere. You might have an existing team doing custom projects that are evolving into something that needs to be owned and sustained by the business. Or, it could also start with an existing code repository where the team will be rolling off or has already left and the need to establish a more permanent presence to maintain and grow the code. Regardless of the situation, consider the following as next steps towards your own transformation:
- Understand who actually is using your code and why. What is the problem they are trying to solve?
- Then, understand how you solve it and what is the value you bring in solving it?
- With that, look at the code and developers and ask ‘when do we test?’. First step in transformation is to design tests first then code. Might need to ensure all existing tests are in a passing state before adding new functionality.
- Next, look at when developers understand acceptance criteria. Verify user stories are refined prior to sprint commencement, not during and align with your end user’s expectations. In order to design tests, developers need to understand the why.
- Build team agreement around DoR and DoD criteria to provide a standard, consistent approach to planned work.
- Build a short-term sprint backlog where the team has a well refined prioritized list of user stories with clear acceptance criteria for the next two (2) sprints.
- Prioritize the long-term backlog to capture, track and build alignment with the wider external stakeholder group (senior management, users, clients). This will help build a shared understanding/agreement on ‘when’ vs ‘what’.
- Communicate a vision. Ultimately, the team and stakeholders should have a clearer sense of where things are today and where they want to be in the future. This alignment will help developers be confident in what they are making will be used and the value it provides.
If you find yourself as a new Product Owner, consider the above as your new role.
For some companies making the transition from project to product teams, the role of Product Owner needs to be clear. Mature Development teams work with a Product Owner to enable all of the above. Their focus should be on looking forward and providing a clear list of ‘to dos’ for the team that align with end users and provide value.
Creating Value
With this in place, the team is able to communicate on a per sprint basis the value being created. Completing user stories leads to completing features and this translates into getting new capabilities in the hands of your users/customers.
The uncertainty is removed.
This translates into increased developer velocity, reducing rework and better user experience overall.
Developers and external stakeholders are aligned and more certain what the code does and does not do. This alignment clarifies the solution and the value it delivers.
Wrap up
In the end, what does a mature team look like?
The team understands who actually is using the code (or the application/service it runs) and why. They understand the value they create for others.
The team meets with a cadence to plan out the next two sprints. The team understands that things can change daily and there is a need to have an agreed forward path that captures this. If things change, you adjust priorities accordingly, otherwise business as usual.
POs and developers use a consistent and standard format to define acceptance criteria. In this acceptance criteria, POs use plain readable language to describe the customer problem and how the application needs to behave. This is captured in a Scenario/Feature file. The developer is able to design tests before writing code and link this with the PO’s Feature file. This is captured in the test file. The developer follows a Red-Green-Blue process to write the right amount of code to satisfy the user’s needs. This is captured in the actual code file.
Ultimate success will be if the team treats the process as gamification. Treating tests and gamifying them will lead to a superior experience for the end user.
Use TDD and BDD together and make it fun and make it permanent.
