TDD v/s BDD
Behavior-driven development (BDD)
What?
Behavior-driven development (BDD) is a software development methodology that emerged in the early 2000s.
It focuses on the behavior of software from the perspective of stakeholders, such as users, rather than just its implementation details.
BDD encourages collaboration between developers, testers, and non-technical stakeholders to ensure that the software meets the desired behaviors and requirements.
Why?
People started using BDD as a response to the limitations of traditional development methodologies, such as a lack of communication between stakeholders and the development team, leading to misunderstandings and misaligned expectations.
BDD emphasizes clear communication through the use of structured natural language specifications, often written in a specific format known as "Given-When-Then" scenarios, which describe the expected behavior of the software in different situations.
Which?
There are several tools available for practicing Behavior-Driven Development (BDD). Some popular ones include:
Cucumber: Cucumber is a widely used BDD tool that allows the creation of executable specifications written in a human-readable format. It supports multiple programming languages such as Java, Ruby, and JavaScript.
SpecFlow: SpecFlow is a BDD framework for .NET that integrates with Visual Studio. It enables the creation of acceptance tests in natural language using the Gherkin syntax and integrates with popular testing frameworks like NUnit and MSTest.
JBehave: JBehave is a Java-based BDD framework that uses natural language to describe the behavior of software. It encourages collaboration between developers, testers, and business stakeholders to define executable specifications.
Behat: Behat is a BDD framework for PHP that utilizes the Gherkin syntax for defining test scenarios. It is often used in combination with Mink, a web acceptance testing framework, to test web applications.
These are just a few examples of BDD tools available, and the choice of tool often depends on the specific requirements of the project and the technology stack being used.
How?
BDD tests are typically written in a more user-centric language, making them more accessible to non-technical stakeholders and facilitating better collaboration between teams.
An example of a BDD test scenario written in Cucumber using the Gherkin syntax:
Now, let's write corresponding unit tests for this behavior. Since unit tests typically focus on testing individual components or units of code, we'll assume that the login functionality is implemented by a LoginService
class with a login
method. We'll use a mock object for simulating interactions with the user interface.
Here's how you might write unit tests for the LoginService
class using a testing framework like JUnit in Java:
In this unit test:
We create a mock
UserInterface
object to simulate interactions with the user interface.We use the
when
method from Mockito to specify the behavior of the mock object when its methods are called.We call the
login
method of theLoginService
class with mock credentials.We use assertions to verify that the login was successful and that the appropriate methods of the
UserInterface
mock object were called.
This unit test validates the behavior of the LoginService
class in isolation from the rest of the system, ensuring that it correctly handles a successful login scenario.
Integration with CI/CD and IDEs
Tools like Cucumber can integrate well with integrated development environments (IDEs) like Visual Studio and IntelliJ IDEA, providing features to visualize scenarios and their associated unit tests.
For example, in Visual Studio, you can use plugins like SpecFlow for .NET projects to integrate Cucumber-like behavior-driven development directly into your IDE. Similarly, IntelliJ IDEA has plugins like Cucumber for Java projects.
These plugins often provide features such as:
Scenario visualization: Stakeholders can view all the defined scenarios in a human-readable format directly within the IDE.
Drill-down approach: Users can click on a scenario to view its details, including the steps involved and any associated unit tests.
Integration with unit tests: The plugins can link scenarios to their corresponding unit tests, allowing developers to easily navigate between the high-level behavior descriptions and the low-level implementation details.
Execution and reporting: Users can execute scenarios directly from the IDE and view detailed test execution reports, including information about which scenarios passed, failed, or are pending.
These integrations help facilitate collaboration between developers, testers, and stakeholders by providing a centralized location within the IDE for defining, visualizing, and managing behavior-driven development scenarios and their associated unit tests.
Comparison between TDD and BDD
Test-Driven Development (TDD)
Behavior-Driven Development (BDD)
Developers are the key participants in TDD
Developers, Customers, QAs are the key participants
Mainly concentrates on unit tests
Mainly concentrates on system requirements
Point of inception is a test case
Point of inception is a scenario
Development centric
Customer centric
Approach: Arrange-Act-Assert
Approach: Given-When-Then
Handy tutorials to get started:
Screen shots from the above tutorial:
Define a scenario:
Generate the glue code (unit test stubs)
Generate HTML results for the scenarios tested:
Last updated