Is it possible to reuse scenarios?

[JPinkney]

Hi, I have a defined scenario :

User starts a workspace with stack
    Given Minishift has state "Running"
    When user triggers workspace creation for stack
    Then workspace should be starting
    When user looks at the workspace status
    Then the workspace status should be running and creation successful

and I was wondering if it was possible to reuse this scenario for multiple stacks? Ideally, I would reuse this scenario for every stack and if that stack failed then I would fail that scenario but not all the tests. Each stack is independent of the others. I'm not sure if this is possible or if I have to manually define each stack as a scenario and do it that way.

[mxygem]

Heya @JPinkney, as far as Cucumber thought itself goes, this sounds like it's a Background or standard Given type setup and you're not actually testing the setup of the stack, yeah?

Some thoughts:

• Scenario reuse isn't something specifically supported by Cucumber. I'm not sure of Godog's implementation in that regard, but regardless, it shouldn't be used. :)
• Not directly related to scenario reuse: while cucumber has the ability to reuse steps, it's not a best practices type of behavior either. If there are scenarios where the same step needs to be requested, the advised solution is to break those behaviors out into helper functions instead. I'd imagine the same type of thing could be applied here.
• Since you're only setting up the stack to be used by a scenario and that scenario is actually testing something else, you'll want to keep that in mind and phrase things accordingly. Using when/then indicates something under test and ideally, you'd only want to have one testable action per scenario.
• Atomic scenarios are very important to avoid having test state creep.

What I would suggest doing is combining your stack setup steps into a single Given step at the beginning of each scenario.

Scenario: Foo triggers bar to be created
  // Manage your setup here
  Given a workspace is started by a user with stack
  // Start your actual test
  When foo is done
  Then bar is created

In this example, your Given step would then call one or more helper functions to set up the workspace as needed. If that process fails, then only that specific scenario will fail, just as you'd like.

Let me know if this makes sense and if you have any questions! @l3pp4rd, if you have anything to add, please do. :)

[l3pp4rd]

yes, you can define step which calls all these steps:

s.Step(`^user workspace is running$`, func() godog.Steps {
        return godog.Steps{
                       "Minishift has state \"Running\"", 
                       "user triggers workspace creation for stack",
                       "workspace should be starting",
                       "user looks at the workspace status",
                       "the workspace status should be running and creation successful",
                }
})

and use it the same way as any step:

Scenario: user does something
  Given user workspace is running
  When action
  Then outcome

[l3pp4rd]

right @JPinkney regarding best practices, also it is recommended to use only one When step.

[JPinkney]

Yes, I agree. My feature files will need to change a tad which is fine! Thanks for your help!

[l3pp4rd]

thanks for your good thoughts @jaysonesmith indeed, scenarios themselves cannot be reused and it would not make sense, but steps can be combined and godog allows that feature to pass them as list, since otherwise you would need to run every one of them (as a separate function call) and check error.

[enkessler]

@JPinkney Just an FYI: nested steps, although technically a feature of Cucumber, have been a bad practice for almost the entire period of its existence. They were not a good idea almost a decade ago and they remain not a good idea today.

[JPinkney]

I didn't end up going with the nested steps idea, it seems possible to do it that way but definitely not a good idea

[l3pp4rd]

Hi @enkessler is there a specific reason why nested steps are considered a bad practice, I may remove them later before going to 1.0.0 version, if there are reasonable arguments

[mxygem]

Hey @l3pp4rd, I'll hop in here and post a reply. I've recently raised this very topic in the CucumberBDD Slack as I'm going to be starting work on writing something up around the deprecation and EOL of nested steps and have received guidance from Aslak.

• While I haven't seen how this is handled in Go, stack traces returned when nested steps fail are generally terrible and don't provide useful information as to where things went wrong, making diagnosing issues difficult.
• Not only does it make following stack traces difficult, but it also increases the difficulty of learning or modifying the test suite due to the obfuscation of functionality.
• Nested steps are a lazy way of trying to stay DRY but in actuality, the better way of handling this type of behavior is to extract reusable pieces of code into helper methods/functions.
• Calling a step is just an inferior way of calling methods to perform automation tasks for you, so why not call the methods directly instead? If they don't exist use that opportunity to improve your suite and make them!

Here are Cucumber's Google Group's search results for discussions around nested steps in case you'd like to read more there too!