I’ve run into this same limitation and would also like to see a @BeforeClass
type of functionality in JBehave. At the moment I’ve worked around this by
breaking the cucumber recommendation and simply having the very first scenario
in the story perform the data setup, and subsequent scenarios
I read a bit The Cucumber Book in order to find best practices when
writing BDD tests. It is very similiar, so I could find some.
When I read across the book, I discovered some cool features which might be
good for JBehave too.
*Background*
For instance there is a feature called Background.
Hi Hans,
thanks for your suggestions, always welcome.
To answer your points:
1. JBehave now supports the Lifecycle Before and After syntax
(http://jira.codehaus.org/browse/JBEHAVE-906):
http://jbehave.org/reference/preview/story-syntax.html
Lifecycle Before is equivalent to Gherkin's
Hello Mauro,
thank you for your answer.
1. Sounds great!
2. I think it could be implemented in a way that story writers don't see
the regex but a parameter name. The regex would be contained just in the
step definition to provide an instant feedback in the story editor on
whether the paramter
Hi Hans,
thanks for starting this discussion. It is rather useful.
I tend to agree with most of the points below but not all.
Notably, I think stories should be independently executable, declaring
via GivenStories all the preconditions they need. Scenarios are not
necessarily independent
Hi,
Parameter value validation could be a useful new feature if it was
configured via annotations.Feel free to raise a new JIRA issue for
this and to add some initial use cases. In particular sometime more
than simply it's a int or a String - because that already comes out of
the box
Hello there,
I'm wondering if someone could give me a point in setting up
jBehave to work with Appium(http://appium.io http://appium.io/ ). Appium
is using selenium WebDriver and I've noticed that jBehave can be used also
with selenium webdriver. I've read some documentation located
