I think I will wait a bit until creating an issue for the paramter validation with regular expressions. I must admit that I currently have no use case for it and need more JBehave experience to assess that.
Concerning multiple example tables: this is really nice to have in my eyes, not more than that. 2013/11/27 Mauro Talevi <[email protected]> > 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 > with the strong typing in Java (which Ruby is missing). But further > validation, e.g. String formatting or other would be interesting to > consider. > > As for having multiple Examples tables, I'm still struggling to see the > benefit of this. Having multiple tables implicitly add complexity and > conventions on how to treat them. If there is not obvious benefit, then > it's not worth it. If anything, one could think about defining sub-parts > within the same table. Again, let's start by outlining the use case for > it. Always open to useful ideas. > > Thanks for contributing your ideas. Most appreciated. > > Cheers > > > On 27/11/2013 12:09, Hans Schwäbli wrote: > > 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 | >> >> >> > >
