Some interesting features I discovered for JBehave

[Hans Schwäbli]

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 |

[Mauro Talevi]

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

Post by Hans Schwäbli
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
/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./
@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
something general which need to be done commonly for all scenarios. So
instance.
*Parameter Validation*
Another nice feature I have discovered in Cucumber is that parameter's
@Given("I have deposited \$(\d+) in my (\w+) Account")
*Grouping 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 |

[Hans Schwäbli]

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

Post by Mauro Talevi
Hi Hans,
thanks for your suggestions, always welcome.
1. JBehave now supports the Lifecycle Before and After syntax (
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
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
*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.*
@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
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
*Parameter Validation*
Another nice feature I have discovered in Cucumber is that parameter's are
@Given("I have deposited \$(\d+) in my (\w+) Account")
*Grouping 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 |

[Mauro Talevi]

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

Post by Hans Schwäbli
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
Hi Hans,
thanks for your suggestions, always welcome.
1. JBehave now supports the Lifecycle Before and After syntax
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

Post by Hans Schwäbli
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
/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./
@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
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
*Parameter Validation*
Another nice feature I have discovered in Cucumber is that
@Given("I have deposited \$(\d+) in my (\w+) Account")
*Grouping 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 |

[Hans Schwäbli]

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.

Post by Mauro Talevi
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
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

Post by Mauro Talevi
Hi Hans,
thanks for your suggestions, always welcome.
1. JBehave now supports the Lifecycle Before and After syntax (
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
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
*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.*
@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
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
*Parameter Validation*
Another nice feature I have discovered in Cucumber is that parameter's
@Given("I have deposited \$(\d+) in my (\w+) Account")
*Grouping 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 |