Details
Bug
Resolved
Major
Description
When story contains Lifecycle Before/After steps, these are executed outside the BeforeScenario/AfterScenario scope for scenarios parametrised by example.
When the JBEHAVE-993 was implemented, runLifecycleSteps is called before runBeforeOrAfterScenarioSteps (and in the reverse order at the end).
Attached is patch with fix and test (patch is based on commit 95dcd85)
Activity
Why do you consider one order more logical than the other? Could you elaborate on your use of the Guice scope?
Mauro Talevi
added a comment - Why do you consider one order more logical than the other? Could you elaborate on your use of the Guice scope? Because the same order (before scenario - lifecycle before - scenario steps - lifecycle after - after scenario) is used for "normal" scenarios, I don't see a reason why it should be different for parametrised scenarios.
We want all objects created by guice to have per-scenario scope. Each scenario (parametrised or not) should start with fresh environment (we are not doing browser-based tests).
We used this description as inspiration: http://codespelunker.blogspot.ie/2013/05/how-to-scope-scenarios-with-jbehave-and.html
Daniel Kolman
added a comment - Because the same order (before scenario - lifecycle before - scenario steps - lifecycle after - after scenario) is used for "normal" scenarios, I don't see a reason why it should be different for parametrised scenarios.
We want all objects created by guice to have per-scenario scope. Each scenario (parametrised or not) should start with fresh environment (we are not doing browser-based tests).
We used this description as inspiration: http://codespelunker.blogspot.ie/2013/05/how-to-scope-scenarios-with-jbehave-and.html Actually, when the order is the same for NORMAL as well as for EXAMPLE scenarios, you can extract the step execution to a new method, that can be used by both cases, with a bonus of reduced duplicity. Isn't that nice? - see beforeAfterExampleWithUnifiedStepExecution.diff
Daniel Kolman
added a comment - Actually, when the order is the same for NORMAL as well as for EXAMPLE scenarios, you can extract the step execution to a new method, that can be used by both cases, with a bonus of reduced duplicity. Isn't that nice? - see beforeAfterExampleWithUnifiedStepExecution.diff Daniel Kolman
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Attachment | beforeAfterExampleWithUnifiedStepExecution.diff [ 65498 ] |
Mauro Talevi
made changes -
| Fix Version/s | 3.9.2 [ 20180 ] |
Daniel Kolman
made changes -
| Attachment | beforeAfterExampleWithUnifiedStepExecution.diff [ 65498 ] |
Daniel Kolman
made changes -
| Attachment | beforeAfterExampleWithUnifiedStepExecution.diff [ 65499 ] |
(sorry the beforeAfterExampleWithUnifiedStepExecution.diff accidentally contained one commit more - it is fixed now. It contains two commits - first changes the order, second extracts the duplicated code into a new method)
Daniel Kolman
added a comment - (sorry the beforeAfterExampleWithUnifiedStepExecution.diff accidentally contained one commit more - it is fixed now. It contains two commits - first changes the order, second extracts the duplicated code into a new method) Yes, you're right. There is an inconsistency and your proposed solution is a good one!
Could you please provide a gitbhub patch, as they one that you've provided does not apply (http://jbehave.org/how-to-contribute.html)?
Please limit patch to StoryRunner refactor and not change the versions in the pom.xml.
Mauro Talevi
added a comment - Yes, you're right. There is an inconsistency and your proposed solution is a good one!
Could you please provide a gitbhub patch, as they one that you've provided does not apply ( http://jbehave.org/how-to-contribute.html)?
Please limit patch to StoryRunner refactor and not change the versions in the pom.xml.
Applied updated patch with thanks.
Mauro Talevi
added a comment - Applied updated patch with thanks. Mauro Talevi
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
I sent you a github pull request, but as I see now it is already merged
Thanks
Daniel Kolman
added a comment - I sent you a github pull request, but as I see now it is already merged Thanks 
This is important for us, because we begin the Guice scope in BeforeScenario method and close it in AfterScenario method, which then affects the construction of step instance used in Lifecycle Before step. There is no workaround we are aware of.