The reasons for JBehave 3
While JBehave 1 was more of a thought experiment, helping to
spread and understand new concepts around BDD. JBehave 2 has been a
complete rewrite based on new technologies (e.g. Java 5 annotations). By
contrast, JBehave 3 is an evolution of JBehave 2, based on the
experience using it in commercial projects. With the benefit of this
experience, we feel that the overall design stood well the wear and
tear, but there were areas which called for improvements that would have
broken backward compatibility.
Migration path from JBehave 2
From the textual stories point of view, these are almost
completely backward compatible. The only exception being the GivenScenarios
keyword, whose default value has changed to GivenStories. Full
backward compatibility can be nonetheless ensures by configuring the
keywords bundle entry to GivenScenarios until the migration has
been completed. See Writing Stories in
your language on how to configure and override default keywords to suit
your needs.
From the Java point of view, significant changes have occurred,
but only in the configuration of the running of the stories. The Steps
classes, which is where most users' efforts will have gone into can be
used without change in JBehave 3.
On the configuration side, the main changes are:
- Terminology has changed throughout to refer to Story in
place of Scenario where this refers to the textual or Java
representation reflecting the fact that scenarios in JBehave 2 were
already stories in all but name. E.g. JUnitScenario is now JUnitStory.
- The root package has also changed from org.jbehave.scenario
to org.jbehave.core. The Ant tasks and Maven goals have also been
renamed to reflect this change.
- Configuration class has been renamed to StoryConfiguration,
along with similar renames for the MostUsefulStoryConfiguration
and PropertyBasedStoryConfiguration, to ensure more consistency
and less confusion with the StepsConfiguration.
- Configurations have shifted to use a builder paradigm.
- JUnitStory allows the overriding of the default
MostUsefulStoryConfiguration only via the useConfiguration
method, and the specification of Steps only via the addSteps
method.
- The textual story lookup paradigm has shifted from a RunnableStory
class to a story path, which can be resolved from the class via the StoryPathResolver,
and its implementations UnderscoredCamelCaseResolver and CasePreservingResolver.
As such, the StoryLoader implementations only define the model
story from a story path. The FilePrintStreamFactory
correspondingly now handles only story paths.
- The concerns of running stories and rendering reports has been centralised in
an embeddable component - StoryEmbedder - which has thin wrappers for
running in multiple environments, e.g. JUnit, Ant/Maven, Spring etc. Using the
StoryEmbedder, the user can choose to run multiple textual story using a single
Java entry point.
- The story runner now renders the reports by default after running the stories,
but behaviour can be changed via renderReportsAfterStories flag.
Next?
JBehave development has been
example-driven and the examples illustrate all the features, migrated
from 2.x or new in 3.x. Be sure check out the running examples, as it's the best and
most instructive way to get up to speed with the changes outlined above.