CODEWITHSUNDEEP
javascriptcucumbergherkincucumberjs
Lee Goddard
Lee Goddard

Reputation: 11173

Gherkin - maintaining state between scenarios

Although I have been writing unit tests for 20-odd years, I am new to Gherkin, and haven been given the task of implementing a story for a .feature file that reduces to something like this:

Scenario: a
    Given that the app is open
    When I open a certain dialog
    Then it has a thing somewhere

Scenario: b
    Given that the dialog from 'a' is open...

# Imagine here a long chain of scenarios, each depending on the previous

Scenario: n
    Given that the previous 'n' steps have all completed....

That is, a long, long chain of scenarios, each depending on the state of the system as configured by its predecessor.

This doesn't feel right to someone used to unit testing -- but these scenarios are not going to be split and run separately.

What's the best practice here?

Should I rewrite into one very long scenario?

I am already using a 'page object' to keep most of my code out of the step definitions -- should I be coding the steps as single calls, that can be re-used in the later scenarios?

I'm running Cucumber in Javascript.

Upvotes: 0

Views: 1717

Answers (2)

Thomas Sundberg
Thomas Sundberg

Reputation: 4323

I would ask myself, what is the actual behaviour behind all the steps?

Then I would implement that as the wanted behaviour and push the order between steps down the stack. Probably using one or many helper classes. There is nothing saying that you can force the order of the scenarios without introducing some hack to force them together.

Remember that BDD and Cucumber is all about human readable communication. The dependencies you are asking for should, in my opinion, be implemented in the support code Gherkin triggers.

Upvotes: 1

kfairns
kfairns

Reputation: 3057

First things first, Warning:

For the majority of tests (and by majority I mean 99.9% of the time), you should not carry on from the previous scenario, because of the fact that if one scenario fails in your feature, more will crumble because you attempted to string them together.

And on to my answer:

Depending on whether you are trying to do a set up for all of your scenarios after (within the same feature), or whether you want to reuse that first scenario multiple times (in separate features), you could do one of 2 things.

  1. Make the first scenario a background
  2. Make the first scenario into a step definition, for use in multiple feature files

For the First:

Background:
  Given that the app is open
  When I open a certain dialog
  Then it has a thing somewhere

Scenario: a
  Given that the dialog from 'a' is open...

Just remember that when you use it as a background, it will be used for all the following scenarios within that feature.

For the Second:

Scenario: a
    Given that the app is open
    When I open a certain dialog
    Then it has a thing somewhere

Scenario: b
    Given I have opened the dialogue from a
    And the '<DialogFromA>' dialog is open...

Upvotes: 1

Related Questions