0

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.

Lee Goddard
  • 10,680
  • 4
  • 46
  • 63
  • Does this answer your question? [gherkins, Can 2 scenarios be dependent on each other](https://stackoverflow.com/questions/59333768/gherkins-can-2-scenarios-be-dependent-on-each-other) – Marit Apr 09 '20 at 09:32

2 Answers2

1

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...
KyleFairns
  • 2,947
  • 1
  • 15
  • 35
  • 3
    I agree with you 99.99% of the time. For the 0.01% of the time you think it's OK to use state from a previous scenario, I disagree. Just my dogmatic opinion. That state requires the scenarios run in a certain order, and not on a grid. – Dave McNulla Mar 31 '16 at 15:55
  • 2
    The only time I would recommend it, is when you are still developing the step definition for the previous scenario, as such that the new scenario still passes in the CI. In a perfect world, the step definition for the previous scenario will be written, however it may be the case that you have a Junior Tester, fresh from university writing the files, who perhaps does not fully understand the language. After the step definition has been created, or the previous scenario has been turned into a Background, it becomes obsolete, and will therefore be changed to the _correct_ way of doing it. – KyleFairns Mar 31 '16 at 16:09
  • Thanks, @KyleFairns -- I've edited the question to try to stress that the feature has a very long chain of scenarios, each one depending on its predecessor. – Lee Goddard Apr 01 '16 at 07:30
  • 2
    The practical reason for it is the speed of browser automation. Let's say I have a scenario that adds to products to a cart, then I see if the cart has two products, then I have a scenario which tests that if I remove those products, I have zero items in the cart. I realize the "best" thing to do from a purist standpoint is in the Delete scenario to add two (using the steps from the first scenario) and then delete them. However, if I have hundreds of tests to run, this is a major time suck and enough of them means no one runs the tests. – Jacob Singh Sep 28 '17 at 18:37
1

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.

Thomas Sundberg
  • 4,098
  • 3
  • 18
  • 25
  • "Remember that BDD and Cucumber is all about human readable communication." --- I think that's the trump card, thank you. – Lee Goddard Apr 04 '16 at 11:15