Add possibility to define actions in certain test case state

[GpeG]

Add possibility to define actions in certain test case state.

For instance, JUnit rule - org.junit.rules.TestWatcher. It allows to define some specific actions for failed or skipped tests.

[vvolverine]

Hey GpeG. Thank you a lot for raising the question.
For this scenario I have idea to utilize the JBehave syntax for story files.
JBehave have very powerful feature named Lifecycle which allows to execute any steps/sequence of steps depends on current phase. Examples can be found by link https://jbehave.org/reference/stable/lifecycle.html
My main idea to implement this options in core of Sprimber, but provide to the end client option to tune this behavior as he want. My vision that end client should work with BDD steps, at feature/story level and details of code implementation should be hidden. By this I'm looking for possibility to add lifecycle elements to the feature/story level.
What do you think? Is it will be convenient to you to utilize the JBehave syntax in your project? If yes, I can start on implementation of this feature in the core of Sprimber. Both Cucumber(Gherkin) and JBehave syntax will be supported. As additional option I can suggest to extend Gherkin language to support this features of lifecycle.

[GpeG]

Hey vvolverine.

I want to use this feature for maintenance purposes. For example, to gather logs and take a screenshot only for FAILED and BROKEN test cases. I think that it relates to implementation layer and should be hidden from test designer.

Lifecycle feature is interesting, but I think that write in each feature something like this is bit inconvenient:

After:
Scope: SCENARIO
Outcome: FAILURE
Given take screenshot
Given gather logs
Given close webdriver

[vvolverine]

Hey GpeG.
Starting from version 1.1.0 Sprimber pushing separate events when before, after or target node were failed.
So, overall event model for steps(small executable portions of code) looks like event that emitted before execution, after success execution or event after error execution. There is no differentiations from core about type of error, but exact Throwable passing as part of event. The same happens for before, after and target step.
Will be it enough for you?