Using BDD for good

Alex Ivanova
Nov 21 · 6 min read

How complicated would it be for you to explain to a 3-year-old child how the web browser works? The same challenge applies to software development as the client domain can be pretty difficult to understand.

We need examples to understand what the client needs. Working with real-world examples helps us to communicate better because we’re able to relate to the problem more easily. To do that, we can use a method called Behavior Driven Development (aka BDD).

Using BDD to create the examples is amazing!

Ok. So how do we do this?

The idea of a BDD test can be narrowed down to:

  • describe a feature in scenarios using a formal text
  • use examples to make abstract things concrete
  • write actual code implementing each step of the scenario

In our examples here we’re going to use Codeception but you are free to use any BDD framework that suits your technology stack. Codeception can generate a feature file for you. We can place our feature files in a bdd directory and create a search feature file:

codecept generate:feature bdd search

This template can be fulfilled by setting actor and goals:

As a(n) actor
I want to do a certain action
In order to achieve a certain goal

In our example, we are going to use the search feature on the website.

Feature: Search
As a visitor
I want to search for paths
In order to find the one that I am interested in

We now need to write the scenario that we are going to use for our automation. Scenarios are written in a step-by-step manner using the Given-When-Then approach.

Here is the template for writing BDD test cases

Given a certain scenario
When an action takes place
Then this should be the outcome

Continuing on our example we can write a scenario that looks like this:

Scenario Outline: Visitor can find a path
Given I am a visitor
When I am on the "search" page
And I filter by <category>
And I search by <keyword>
Then I see the correct <path>
| category | keyword | path |
| "paths" | "dev" | "Junior Web Developer" |
| "paths" | "ai" | "AI Engineer" |

Here we are using an advanced technique where by using a Scenario Outline we can set up Examples in order to run our test multiple times with different parameters. The values are replaced with the placeholders <category>, <keyword> and <result>, which are filled by the Examples table. Each set of values is executed as a different test.

In Codeception we can test this scenario by executing it in dry-run mode:

codecept dry-run bdd search.feature

We should now define the scenario steps easily by executing:

codecept gherkin:snippets bdd

To match steps from a feature file to PHP code we use annotations which are then added to methods. Steps can also be matched with regex expressions and parameters can also be passed in non-regex strings using the : params placeholder.

Here is an example using the steps defined in our scenario:

* @Given I am a visitor
* @When I am on the :page page
* @When I filter by :category
* @When I search by :keyword
* @Then I should see the correct :path

Steps are defined in Context files. The default context is an actor class, i.e. for the bdd testing suite, the context is BddTester class. You can define the context in a bdd.suite.yml file like so:

— BddTester

We then connected the annotations to pre-existing methods in our automation framework based on Codeception. Re-using existing code is always great 👍

Here are a couple of examples:

* @Given I am a visitor
public function iAmAVisitor()
* @When I am on the :page page
public function iAmOnThePage($page)
* @When I filter by :category
public function iFilterByCategory($category = 'all')
Photo by Paul Hanaoka

How specific should we get?

Based on my experience, whether you’re using BDD as a sole solution for creating your test automation framework or you’re using it in only a few end-to-end tests, it is better to make your steps as readable as possible. For the most part, this means being less specific and getting into the details only in your methods (back in the code base of your automation) but not in your BDD feature files.

At OpenClassrooms we use BDD to create some long end-to-end scenarios. While keeping shorter and more specific tests using pure Codeception framework. Some examples of end-to-end tests on our platform include:

Visitor can sign up and become a self-paid student.
Student can get their projects validated and finish their path.
Mentor can create a mentorship session and evaluate their student’s progress.
Assessor can create a presentation sessions and evaluate student’s project.
Admin can create a new course.

To BDD or not to BDD?

Benefits of using BDD

  1. Promotes better communication between members of the team.
  2. Defines acceptance criteria prior to development.

Disadvantages of BDD

  1. Testers using BDD need to have sufficient technical skills.
  2. It is less flexible than pure code.
  3. It adds additional complexity to your framework.


I know it’s not a magic bullet but I’m really hopeful it will improve the requirements gathering and testability of our application.


For more information on setting up your own BDD automation framework with Codeception, you can go to the BDD Codeception documentation.

For more information on the paths and courses available on the OpenClassroms platform, you can search for your favorite topics at the OpenClassrooms search page.



Thanks to arnaud lefevre

Alex Ivanova

Written by




Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade