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 |
