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]
<mailto:[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 |
