My team is just starting with BDD, and we are learning to write scenarios in a GIVEN, WHEN, THEN format. This will position us to start to automate our tests (with selenium) at the start of sprint, so that we fail until the application code catches up to satisfy the test(s).

We are thinking that the automation of our scenario is rigid, and defines the expected case, but when we take on a story, that is going to introduce (for example) a field or button that doesn't yet exist, how should we manage the automation. Would we

  1. write the automation as far as we can go, and when a real locator id is known with certainty, update both the application code and test together?


  1. write the automation case defining an explicit id that we are then obligated to match when the application code is written.

This is sort of a chicken - egg proposition. Am I being too rigid on how specific the actual automation is, and should I be content that my GIVEN-WHEN-THEN statement is accurate enough?

  • Just a small tip. BDD is not about testing user interface, you are going into a lot of trouble with selenium and BDD. Maybe try to test your REST API or even lower layers (ports) if you can. May 9, 2019 at 11:22

2 Answers 2


If you have a structure in place and good requirements you should be able to write tests which will pass when the code is written.

So for example if you are using selenium you can give the imaginary button an id and look for it, click on it and then look for the expected update.

Obviously everything will fail at the first hurdle and you can't test your test. But all being good things will start automatically turning green as you add the button and its click effect.

This is the ideal case, but you are usually going to have to come back and tweak tests as you develop code and or requirement details change. Just failing each step until you have the structure there to write passing tests is sometimes the best you can do.

  • Most of our application code can use id's for locators, but our agile process doesn't get into the nitty gritty of id assignement of objects. I figure we'll likely make a buest guess for a locator, and if needed may need to tweak the automation to remain true to the Gherkin description.
    – EALJAS
    May 8, 2019 at 16:56
  • 4
    @EALJAS: The idea behind agile processes is that people talk to each other, rather than throwing something over a wall. So, go talk to the developer working on the code and discuss what would work best for the two of you to identify that new button/field/whatever. May 9, 2019 at 8:15

This is where an intermediate language like Gherkin becomes beneficial. It allows you to record a use case without writing any of the code to support that test. For example, say you are building a blog. This sprint you decide to add comments to blog posts. Using Gherkin you can write your tests by adding a new feature file:

Feature: Adding comments to a blog post
    In order to interact with blog post authors
    As a reader who is a registered user
    I want to comment on a blog post

Scenario: Commenting on a blog post
    Given "Bob" is a registered user
    And a blog post exists
    And "Bob" has logged in
    When the user comments on the blog post: "Great info!"
    Then the blog post should have the following comments:
        | Comment     |
        | Great info! |

Many IDEs will support syntax highlighting of Gherkin files, including matching them to step definitions. If a step is not defined, it gets displayed as a different color.

Now at least you have the test case written down. Part of the effort to bring this story to fruition is to implement all of the test infrastructure code, which includes missing step definitions and Selenium page models.

Remember to phrase your steps using business terms and language. Stay away from user interface related terms like "button" or "link" and certainly do not hard code CSS selectors or XPath locators in your scenarios. Buttons, links, and locator strategies are concerns for your Selenium page models, not your scenarios or even step definitions.

By phrasing your steps using business language you don't need to know any technical details ahead of time. They can be filled in as part of development, and this effort can be captured in your story point estimates.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.