|
||||||||
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
- [jbehave-dev] [jira] (JBEHAVE-831) Pre- and postcondit... Olmo Rigolo (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-831) Pre- and postc... Olmo Rigolo (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-831) Pre- and postc... Mauro Talevi (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-831) Pre- and postc... Mauro Talevi (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-831) Pre- and postc... Olmo Rigolo (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-831) Pre- and postc... Mauro Talevi (JIRA)
- [jbehave-dev] [jira] (JBEHAVE-831) Pre- and postc... Olmo Rigolo (JIRA)
It's true that @Before and @After annotations have the drawback of not being visible in the stories, but that's the point. They are background tasks that get executed before/after every story or scenario.
I'm not sure how the syntax you propose for Before/AfterScenario is any different from a straight invocation of steps.
Perhaps something like invocation of scenarios as part of another scenario would be more useful:
Scenario: User is operator by default
RunScenario /path/to/user_management.story#create_user
Given user <login> on login page
Then ensure operator link is visible
RunScenario /path/to/user_management.story#delete_user