organizer is just learning JBehave, and hasn't written a production-quality
test in it yet. Anyone who knows more
should (as always) feel free to step up and use the practices they're familiar
I'm not yet decided
on whether the benefits outweigh the costs in using JBehave - let's talk about
it in our retrospective at the end of this session.
Let's do this in two
- Part 1 is a tutorial where we review the what & why
of JBehave and set up the environment.
- Part 2 is the "Code Dojo" part where we create
What is JBehave?
- A behavior-driven-development (BDD) framework for
- It differs from EasyB (used on Career Transitions with
mixed success) in that it does not require another language (Groovy), and
it outputs test results with the red-bar-green-bar format of JUnit.
Why use it?
- It runs tests using JUnit, which we are all familiar
- It allows users (or developers working with users) to
write test scenarios with an English-like syntax.
- The Reader team really likes it, and has had good
success with it.
Why not it?
- The normal stacktrace from JUnit isn't very useful when
a test fails. (You have to look at
the console output.)
- it's another tool to learn.
- Add a dependency to JUnit (JBehave requires this)
- Add a dependency to JBehave to the project's POM
- Add dependency (for this example) to the commons-io jar
used by FancyScenarioBase.
Example JBehave Test
The example contains
- A scenario file that contains the English-like scenario
we want to run through.
- A steps file that matches the scenario statements (using
annotations) to executable methods.
- A test file that glues this to JUnit and runs the tests.
Let's use our
"Text Replacer" as a (very) simple example to set up our tests. If nothing suggests itself, we can write a
couple of individual scenarios, then create a single table-driven version.