The reasons for JBehave 3
JBehave 1 was more of a thought experiment, helping to spread and understand new concepts around BDD.
While JBehave 2 has been a complete rewrite based on new technologies (e.g. Java 5 annotations), JBehave 3 is more
of 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:
- JUnitScenario class has been renamed to JUnitStory, reflecting the fact that scenarios in JBehave 2
were already stories in all but name.
- Terminology has changed throughout to refer to Story in place of Scenario where this refers to the
textual or Java representation. Scenario now refers uniquely to the constituent part of a story. The root package
has also changed from org.jbehave.scenario to org.jbehave.core.
- 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.
- JUnitStory allows the overriding of the default MostUsefulStoryConfiguration only vis the the useConfiguration
method
- JUnitStory allows 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 StoryDefiner implementations only define the model story
from a story path.
- The FilePrintStreamFactory correspondingly now handles only story paths.
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.