Announcing Cucumber-JVM v2.0.0
I am excited to announce the release of Cucumber-JVM v2.0.0.
Here follows a summary of notable changes, and the non backward compatible changes.
The full change log is available here.
Most importantly note that the Maven group id is changed.
Maven group id
The Maven group id is changed to
Gherkin v4 and Pickles
The Gherkin library is updated from version 2.12.2 to version 4.1.3. This is
a complete rewrite using new design principles. One of the more visible
consequences for Cucumber-JVM is that the feature files are compiled into a
set of Pickles
(one Pickle for each Scenario and one for each Example Table row),
which form the basis for the execution. The Pickle is converted to a Test Case
before the actual execution by matching the steps to step definitions and adding
steps for the hooks. The execution in Cucumber-JVM v1.2.5 was based on
iterating over the feature file. This change has consequences for the formatter
interface, see the "Non backward compatible changes" section below.
As of v2.0.0, time stamped events are used internally to notify significant steps
during the execution of Cucumber-JVM. The events
sent during the execution of Cucumber-JVM are:
TestRunStarted- the first event sent.
TestSourceRead- sent for each feature file read, contains the feature
SnippetSuggestedEvent- sent for each step that could not be matched
to a step definition, contains the raw snippets for the step.
sent before starting the execution of a Test Case(/Pickle/Scenario),
contains the Test Case
sent before starting the execution of a Test Step, contains the Test Step
scenario.embedin a hook triggers this event.
scenario.writein a hook triggers this event.
TestStepFinished- sent after the execution of a Test Step, contains the
Test Step and its Result.
TestCaseFinished- sent after the execution of a Test Case(/Pickle/Scenario),
contains the Test Case and its Result.
TestRunFinished- the last event sent.
The changes with respect to Java 8 includes:
method references can be used in lambda step definitions.
lambda steps are allowed to throw checked exceptions.
It is no longer possible to use lambda step definitions without also using
By default it is the Test Cases(/Pickles/Scenarios) that are the leafs in the
test suite tree. The structure of the test suite tree is
Runner class -> Feature -> Test Case(/Pickle/Scenario). The old behaviour where
the Steps are the leafs in the test suite tree can be activated with the
As of v2.0.0, the
TestStarted notification is always fired before the test is started,
--junit,--allow-started-ignored option has no effect and is deprecated.
This change in notifications is enabled by using the
to make Undefined and Pending Scenarios be marked as skipped.
As of v2.0.0, it is the Test Cases(/Pickles/Scenarios) that are mapped to TestNG tests.
As of v2.0.0, the Tag Expression library
is used to parse the
--tags options and the tags conditions on hooks.
--tags 'not @foo or @bar' or
Before("@foo and @bar") can
therefore be used. The old syntax for "not" (
~@foo) and "or" (
@foo,@bar) is deprecated.
Tag, name, and line filters can coexist
For instance it is possible to use
--tags @foo classpath:path/file.feature:3.
The different filters are combined with "and" (all must be fulfilled). One
practical use of this is when the test run that generated a rerun file was using
--tags option, then that
--tags option does not need to be removed when
using the rerun file, which was the case in v1.2.5.
Ambiguous as a separate result type
In v1.2.5 ambiguous step (more that one step definition matches the step) were
failed result type. As of v2.0.0, we follow the lead of Cucumber-JS and use a
ambiguous result type for ambiguous steps. A summary like
2 Scenarios (1 Passed, 1 Ambiguous) may occur with v2.0.0.
Non backward compatible changes
As of v2.0.0, formatters are Event Listeners that listen for events. The
formatter registers itself as a handler for the events it needs to listen to,
and then processes the events received to produce its output. See the
"Event Model" section above for a listing of the available events, and for
instance the source code of the Json Formatter
for an example.
Data available to hooks
Two of the methods in the
Scenario object available to hooks have changed.
As of v2.0.0, the
getStatus method returns an Enum instead of a String.
scenario.getStatus().lowerCaseName() the same string that was returned
in v1.2.5 can be obtained. To check what the status value is, statements like
scenario.getStatus() == Result.Type.FAILED can be used.
As of v2.0.0, the
getId method returns the string
<feature file uri>:<line number>.
In v2.0.0, when Pickles are the basis for the test execution, the data used in v1.2.5
(like "feature id", "examples id") is no longer available during the execution.
Full change log