cucumber / cucumber-js

Cucumber for JavaScript
https://cucumber.io
MIT License
5.01k stars 1.09k forks source link

Inject steps at runtime #2383

Closed cjmarkham closed 3 months ago

cjmarkham commented 3 months ago

πŸ€” What's the problem you're trying to solve?

Given a background with multiple steps, each communicating with an API, we'd like the ability to "inject" a step after each of the steps in the background. The idea is that we want to make sure the API request was a success ad fail early if not.

For example, given the following Background:

Background:
  Given I create a resource
  And I create another resource

The steps would be changed at runtime (without affecting the Gherkin document) to become:

Background:
  Given I create a resource
  Then the response is successful
  And I create another resource
  Then the response is successful

✨ What's your proposed solution?

I don't think it's possible to manipulate the steps in a hook, but this could be a use case for a plugin. If we listen to an event and get information on the step type ("Context" in this example), then we could do our own assertion and exit early if it fails.

⛏ Have you considered any alternatives or workarounds?

There's an obvious one and that's to add the "Outcome" step manually. While it works, it causes a bit of a mess when your backgrounds have several steps in them.

The other way to resolve this is just to do the assertion in the step. However, we've decided that having the step do the request and the assertion is mixing concerns, only "Outcome" steps should be making assertions.

The other option is to manually add a catch all to the bottom of the Background: "Then all requests are successful".

πŸ“š Any additional context?


This text was originally generated from a template, then edited by hand. You can modify the template here.

davidjgoss commented 3 months ago

Injecting fresh steps dynamically at runtime isn't something we'll be doing, it would be a big departure from the current model of Cucumber.

The other way to resolve this is just to do the assertion in the step. However, we've decided that having the step do the request and the assertion is mixing concerns, only "Outcome" steps should be making assertions.

I see where you're coming from here, and it's good to avoid mixing concerns, but it's generally an accepted practise to do assertions like this on context steps. They're in a different category to assertions that validate functional outcomes, because they're just about ensuring the state is as expected.