1

I have started to use Selenium + BDD Cucumber and I find these two technologies working quite nicely together. I am a bit concerned regarding the approach to what can be improved much more if Cucumber was offering BeforeAll and AfterAll annotations to achieve faster verification on specific areas with a more granularity. Say for example I wanted to write this scenario (I am being generic on purpose just to show my point)

Scenario Outline: The customer can update their details
Given I am logged in the platform
And I navigate to my details page
When I update "field" in my details
And Save
I should see the "field" updated
Example:
 |field   |
 |name    |
 |surname |
 |address |

Being a scenario outline that means it's going to be executed 3 times as 3 separate scenarios. The problem I see here is that every time the scenario will start from scratch, giving you the delay of logging in every time (or in general to perform all the actions to get you to the point you want to be).

One can use @Before but doesn't change much because these actions will be executed anyways every time (and also I am not entirely sure that is the right way of doing things in BDD).

Some people are suggesting to alternate the checks for each field in a series of When/Then that seems to be against the BDD basic principles. Also in this specific case it means that the 3 scenarios will be compacted in one and if the customer fails to update the name field, the others will not be executed giving me a pass rate of 0% whilst it could be 66% (assuming for simplicity we only have 1 scenario and the other two fields are successfully updated). Moreover if updating name has a bug as well as updating address I will only be aware of the problem in the first one and understand about the other only when the "updating name" steps succeeds.

A BeforeAll would probably solve the problem but it's not available in Cucumber.

What I would like to achieve is to perform a series of steps to get to as specific page and then perform tests per field (or with a different level of granularity) and execute all of them in a "when I do this, then I should see that..." fashion so that if anything fails I know what fails and what passes but at least I am sure everything has been covered and not skipped because previous steps have failed.

Apologies for the long post but I was hoping to explain my view as best as possible. Not sure if it's clear or makes sense at all.

Thanks for your replies

Giuseppe Salvatore
  • 717
  • 1
  • 8
  • 18

1 Answers1

1

Limiting this to one scenario per field is being too rigid for BDD. I like to think of a scenario as a distinct behavior coupled to an assertion that ensures the behavior is functioning. It would be appropriate to test that all the fields are being updated, unless a group of fields can be isolated as a separate behavior, for instance changing your email should send a verification. That should be a separate scenario from the fact the email field gets updated.

This is where data tables become nice to use. Specify a data table for the fields you want to update so you can specify multiple fields in a single scenario. You can use a data table in your assertion in order to compare multiple fields at once.

Scenario: The customer can update their details
    Given I am logged in the platform       
    And I navigate to my details page
    When I update my details with:
        | Field   | Value        |
        | Name    | Bob          |
        | Surname | Jr           |
        | Address | 123 Smith St |
     And Save
     Then my details should be:
        | Field   | Value        |
        | Name    | Bob          |
        | Surname | Jr           |
        | Address | 123 Smith St |
Greg Burghardt
  • 17,900
  • 9
  • 49
  • 92
  • I thought that scenario outline was useful when you needed to make data visible across the whole scenario and tables when data is only needed in a specific step. In fact here you are forcing a duplication of data in two steps by using tables. Maybe the example I made up was too simple to show what I meant... – Giuseppe Salvatore Oct 27 '19 at 10:45
  • @Giuseppe using this answer as a springboard, you could always build a picture of the [state of the system](https://cucumber.io/docs/cucumber/state/) under test in the backend - and when you update the fields, update a variable or set a value in your cucumber world object. This'll mean you'll only have to state the values once, and you'll be able to reuse them, changing the last step to: "Then my details should have been updated" – KyleFairns Oct 30 '19 at 11:37
  • @KyleFrains, I don't understand. You are suggesting to still use a table in the When and change the Then not to use it by being more abstract? This way 1. I still need to pass the status across steps (which I think as you are suggesting it's not a problem) 2. I will lose that nice level of granularity and if my test fails because of Name field, and potentially because of the Address field, I will only get the failure due to a problem in name, because the other checks on the other two fields will probably not be executed (unless you implement a more complex logic) – Giuseppe Salvatore Nov 06 '19 at 21:04