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 value is valid. Otherwise these kind of mistakes can only be displayed later at the execution time of the story. But it is okay for me. 3. I see. It was meant as "nice-to-have" maybe, it is not really required as you said. Bye 2013/11/27 Mauro Talevi <[email protected]> > 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 background. > > You can try out this feature in the latest beta (3.9-beta-3). > > 2. JBehave parameters are implicitly validated by the fact that they > correspond to strongly typed Java variables. JBehave does not expose the > regex in the step patterns, as it's considered an implementation detail. > Moreover as some scenario writers are non-technical it would be baffling to > them (and not just to them - regex is not exactly a user-friendly syntax). > > 3. The examples table can be separated in groups by comment lines. > > Cheers > > > On 27/11/2013 08:29, Hans Schwäbli wrote: > > 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". Here is the > description from the book: > > *A background section in a feature file allows you to specify a set of > steps that are common to every scenario in the file. Instead of having to > repeat those steps over and over for each scenario, you move them up into a > Background* > *element. There are a couple of advantages to doing this:* > > - *If you ever need to change those steps, you have to change them in > only one place.* > - *The importance of those steps fades into the background so that > when you’re reading each individual scenario, you can focus on what is > unique and important about that scenario.* > > It seems to be the same concept like JUnit's @Before or even > @BeforeClass. In JBehave you can do this with "GivenStories". But this is > maybe not the same, if Background seems to be executed before each scenario > starts. And the readability is better with a Background definition where > you can read the steps in the same story file. > > But what is missing, even in Cucumber, is to declare in the story what > happens after a scenario or a story has finished. In JUnit you have @After > and @AfterClass for this purpose. This is typically used for clean-up and > is executed even if the tests fails. The story knows best what it has to > clean-up. But there needs to be a way how that clean-up per story is > executed even if the story fails. I think even clean-ups per scenario would > be good to have. I think I haven seen JBehave annotations for > @AfterScenario and so on, but it is meant for something general which need > to be done commonly for all scenarios. So it is not comparable to JUnit's > concept and behavior of @After for instance. > > > *Parameter Validation* > > Another nice feature I have discovered in Cucumber is that parameter's are > validated by regular expressions. Here an example: > > @Given("I have deposited \$(\d+) in my (\w+) Account") > > > *Grouping Examples* > > Yet another nice feature I have seen is to group examples: > > Examples: Successful withdrawal > | Balance | Withdrawal | Outcome | Remaining | > | $500 | $50 | receive $50 cash | $450 | > | $500 | $100 | receive $100 cash | $400 | > > Examples: Attempt to withdraw too much > | Balance | Withdrawal | Outcome | Remaining | > | $100 | $200 | see an error message | $100 | > | $0 | $50 | see an error message | $0 | > > >
