DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. What Is BDD and What Does It Mean for Testers?

What Is BDD and What Does It Mean for Testers?

A software development strategy that makes sense for both your business team and tech team.

Federico Toledo user avatar by
Federico Toledo
·
Feb. 19, 19 · Opinion
Like (10)
Save
Tweet
Share
23.54K Views

Join the DZone community and get the full member experience.

Join For Free

Behavior-Driven Development (BDD), as its name indicates, is not a testing technique, but rather a development strategy (as well as TDD, which is Test-Driven Development). What it proposes is to define a common language for the business and the technical team members, using it at the outset of development and testing, which is why it's important for testers to understand BDD.

The Basics of BDD in Testing

BDD and TDD 

I used to think about BDD as an evolution of TDD, but then I realized that it is much more than a simple evolution. It's a different approach that solves a different problem. In TDD, the focus is on the unit test, while in BDD, the focus is testing on a higher level, functional and acceptance testing, as its aim is to comply with the business and not just with the code.

Both approaches may coexist since an acceptance test could be specified and then refined into unit tests when coding that functionality in the different layers. Perhaps a clear advantage of BDD is that the developers focus on understanding the functionality and how it works at a business level.

BDD in Agile Methodologies 

This strategy fits well in the Agile methodologies since, generally, requirements are defined as user stories. These user stories must have their acceptance criteria which are used to define acceptance tests, that can be written directly in a specific language called Gherkin.

A Common Language for Business and Tech: Gherkin 

Gherkin is a very simple language which can be written by someone who does not have a programming background, but at the same time, it can be understood by a computer program in order to use it as a test specification.

Typically, these tests will be stored in ".feature" files, which should be versioned together with the source code of the system being tested. Here's a simple example taken from Cucumber :

These files specify:

  • Feature: the name of the functionality to be tested, the title of the test
  • Scenario: one scenario for each test that you want to specify for this functionality
  • Given: the preconditions
  • When: the actions that are going to be executed
  • Then: the expected result, the validations to be made

We usually have one per file and it will contain different test scenarios.

Note: Gherkin supports many languages, so although the most common is to see it in English, it can be in other languages as well.

Who writes the acceptance tests?

It depends greatly on each team, but acceptance tests can be written by the Product Owner or someone else from the team, like a tester or developer. Perhaps a good option is to do it together, at least the brainstorm, as a part of the story refinement. Then, the tester could be responsible for ensuring that the acceptance tests are well-written and have the proper coverage according to the defined testing strategy.

BDD and Testability 

The BDD approach favors system testability. I dare to say that this scheme works better with microservice architecture than with monolithic systems because the former allows adding and working on all layers independently per feature. This scheme facilitates testing as we think about the test before any line of code, thus providing greater testability.

This reminds me of the Scrum Master course I took by Peregrinus, where the instructor mentioned that in Agile, the important thing is to know how to "cut the cake."

Think of a multi-layered cake. Each layer adds a new flavor that is to be combined with the other layers.

If the cake is cut horizontally, some people may only get the crust, some a chocolate middle layer, another a layer of vanilla, or a mix of the two, etc. In this scenario, no one would get to taste the cake as it was fully meant to be enjoyed and no one could say they actually tasted the cake.

The same happens with the approach of writing a user story per component. Everything can work well separately, but upon integration, thousands of potential problems can appear.

That is why the stories are compared to a cake slice (When cut the right way, vertically!). This slice should include everything from the crust to the frosting so that you can try ("test") everything together.

That is, there shouldn't be a story like "implement XX functionality in the data access layer" because it's not business oriented.

BDD works best facilitating and promoting having a testable system, where the cake is cut well, focusing the stories towards a business functionality and implementing it with all of its layers completed.

BDD for Automating Tests 

The Gherkin language is simply text with some keywords and a bit of structure. Tools like it allow us to implement a connection layer between the test specification and the interface of the system to test, which also can be used as the steps of an automated test.

To start practicing, there's a great Google Chrome plugin called Tidy Gherkin. You can write the features in the text field above, and show what code is the necessary code to execute those steps in different languages (Java, Ruby, and JavaScript).

BDD in Action 

A good way to work with BDD might look like this (this is just one example that works for us in many projects, but it's not the only one we're using):

  • Having a system architecture that allows for working in "slices," where stories are only finished when completed from end to end. The cake well cut!
  • When the stories are refined, write the acceptance tests in Gherkin (a tester can do it without programming knowledge).
  • At the start of the sprint, while there are no stories ready for testing, the automator (could be the tester) works on removing technical testing debt.
  • Once a story is ready to be tested, perform exploratory testing in order to give early feedback and also determine if the feature and its acceptance test can be automated. If so, then implement the layer that connects the feature file with the system interface. This can be done using Cucumber with some language (Java, Ruby, etc.) and with an appropriate driver, which could be Selenium for web, Appium for mobile, or RestAssured for web services.
  • Version the test code, the system code and the features with the same criteria.

What are your experiences with BDD? Let me know in the comments!

Further reading

How to Test Software, Part II: TDD and BDD

unit test scrum agile IT

Published at DZone with permission of Federico Toledo, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Internal Components of Apache ZooKeeper and Their Importance
  • DevOps Roadmap for 2022
  • Debugging Streams and Collections
  • Real-Time Stream Processing With Hazelcast and StreamNative

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: