Details
Improvement
Resolved
Major
Description
We need to improve the state management of the StoryRunner.
Currently after every set of steps run the state is reset and the scenario @Before/@After steps are run separately from the normal steps, causing wierd behaviours when there are failure in the @Before steps but not in the normal steps. Examples of such a behaviour are the trader failing_before_after.story and failing_before_stories.story.
A better and more intuitive state management should be in place, keeping state in the run context. The state should be reset by default before each scenario (to ensure backward compat) but will be shared between the @Before/@After steps and the normal steps.
We should also have the option to not reset it before each scenario to allow for failures in the @BeforeStory/Stories steps to propagate to the scenario steps in the same run context.
Once a failing state in a given run context, the steps that follow will not be performed, as customary with normal steps.
Activity
Mauro Talevi
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Summary | Scenario steps are being executed after a failure in a @BeforeScenario/Story | Scenario steps should be not performed after a failure in a @BeforeScenario/Story |
Mauro Talevi
made changes -
| Summary | Scenario steps should be not performed after a failure in a @BeforeScenario/Story | StoryRunner should manage state at scenario level |
| Issue Type | Bug [ 1 ] | Improvement [ 4 ] |
| Description |
This is a regression in 3.3, as it was working up to 3.2.
The trader failing_before_after.story verifies the correct behaviour. |
We need to improve the state management of the StoryRunner.
Currently after every set of steps run the state is reset and the scenario @Before/@After steps are run separately from the normal steps, causing wierd/wrong behaviours when there are failure in the @Before steps but not in the normal steps. An example of such a behaviour is the trader failing_before_after.story. If we use the storyFailure to drive the state it causes other behaviour to break. A better and more intuitive state management should be kept at scenario level. We should instead hold a reference to a scenarioFailure which can be reset before each scenario but will be shared between the @Before/@After steps and the normal scenario steps. |
Mauro Talevi
made changes -
| Status | Open [ 1 ] | In Progress [ 3 ] |
Mauro Talevi
made changes -
| Summary | StoryRunner should manage state at scenario level | Improve state management of StoryRunner |
Mauro Talevi
made changes -
| Description |
We need to improve the state management of the StoryRunner.
Currently after every set of steps run the state is reset and the scenario @Before/@After steps are run separately from the normal steps, causing wierd/wrong behaviours when there are failure in the @Before steps but not in the normal steps. An example of such a behaviour is the trader failing_before_after.story. If we use the storyFailure to drive the state it causes other behaviour to break. A better and more intuitive state management should be kept at scenario level. We should instead hold a reference to a scenarioFailure which can be reset before each scenario but will be shared between the @Before/@After steps and the normal scenario steps. |
We need to improve the state management of the StoryRunner.
Currently after every set of steps run the state is reset and the scenario @Before/@After steps are run separately from the normal steps, causing wierd behaviours when there are failure in the @Before steps but not in the normal steps. Examples of such a behaviour are the trader failing_before_after.story and failing_before_stories.story. A better and more intuitive state management should be in place, keeping state in the run context. The state should be reset by default before each scenario (to ensure backward compat) but will be shared between the @Before/@After steps and the normal steps. We should also have the option to not reset it before each scenario to allow for failures in the @BeforeStory/Stories steps to propagate to the scenario steps in the same run context. Once a failing state in a given run context, the steps that follow will not be performed, as customary with normal steps. |
Mauro Talevi
made changes -
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
Mauro Talevi
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | Resolved [ 5 ] | Reopened [ 4 ] |
Mauro Talevi
made changes -
| Status | Reopened [ 4 ] | In Progress [ 3 ] |
Mauro Talevi
made changes -
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
The refactor has broken the failure UUID correlation between stories (
JBEHAVE-490).Added FailureCorrelationStories in trader example to reproduce behaviour.