0

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?

OR

  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. – Rafał Łużyński May 9 at 11:22
1

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 at 16:56
  • 2
    @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. – Bart van Ingen Schenau May 9 at 8:15

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.