Details
New Feature
Open
Minor
Description
Problem:
The different ways to define a single scenario and its logic makes it hard to understand test logic.
Example:
I have two test suites calles RegistrationProcessStory ond AccountingStory.
The RegistrationProcessStory is a jbehave story containing logic for test data preparation like BeforeStory, AfterStory and BeforeScenario(onOutcome=Failure) etc.
The AccountingStory contains similar test data logic.
A Given statement is something like a BeforeScenario (i.e. @BeforeScenario(uponType = ScenarioType.EXAMPLE)).
So my problem is, that we have test data preparation logic in a .story file. but we could have another logic hidden in the implementation of a testsuite. (@BeforeScenario) On the other hand, test cleanup logic can't be described in a .story file, but in the TestSuite logic (@AfterScenario, @AfterStory)
Solution:
I would like to have an extension to the BDD vocabulary, that enables pre- and postcondition descriptions in a .story file.
This could be a simple mapping of the annotations to a keyword like:
Scenario: User is operator by default
BeforeScenario create user <login> with data <dataentries>
Given user <login> on login page
Then ensure operator link is visible
AfterScenario delete user <login>
What do you think about the idea?
Greetings, Olmo
Activity
Mauro Talevi
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Issue Type | Bug [ 1 ] | New Feature [ 2 ] |
Mauro Talevi
made changes -
| Comment | [ Sorry, this is not a bug. Can't edit it. ] |
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
Mauro Talevi
added a comment - 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
Hi Mauro,
the problem is that create user is not a real world scenario. For instance, there is no UI for it.
Create user would be exactly the code of a @BeforeScenario method.
In your proposal, if there would be a story#scenario file for it, this would only be one sentence. The content of /path/to/user_management.story#create_user: would be sth. like that
Scenario: create User
Given a new user <login> with data <dataentries>
Examples:
login|dataentries
bla|
I think your proposal makes sense for more complicated tests, but its only an extension (in case of tear down) of the GivenStories keyword.
Olmo Rigolo
added a comment - Hi Mauro,
the problem is that create user is not a real world scenario. For instance, there is no UI for it.
Create user would be exactly the code of a @BeforeScenario method.
In your proposal, if there would be a story#scenario file for it, this would only be one sentence. The content of /path/to/user_management.story#create_user: would be sth. like that
Scenario: create User
Given a new user <login> with data <dataentries>
Examples:
login|dataentries
bla|
{Test, User, Teststreet 3, Berlin, Germany}
I think your proposal makes sense for more complicated tests, but its only an extension (in case of tear down) of the GivenStories keyword. 
thx for changing issue type