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.

Notable Changes

Maven group id

The Maven group id is changed to io.cucumber.

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.

Event model

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
    file source.

  • SnippetSuggestedEvent - sent for each step that could not be matched
    to a step definition, contains the raw snippets for the step.

  • TestCaseStarted -
    sent before starting the execution of a Test Case(/Pickle/Scenario),
    contains the Test Case

  • TestStepStarted -
    sent before starting the execution of a Test Step, contains the Test Step

  • EmbedEvent - calling scenario.embed in a hook triggers this event.

  • WriteEvent - calling scenario.write in 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.

Java 8

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
    cucumber-java8

JUnit module

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
--junit,--step-notifications option.

As of v2.0.0, the TestStarted notification is always fired before the test is started,
so the --junit,--allow-started-ignored option has no effect and is deprecated.
This change in notifications is enabled by using the AssumptionFailed notification
to make Undefined and Pending Scenarios be marked as skipped.

TestNG module

As of v2.0.0, it is the Test Cases(/Pickles/Scenarios) that are mapped to TestNG tests.

Tag Expressions

As of v2.0.0, the Tag Expression library
is used to parse the --tags options and the tags conditions on hooks.
Expressions like --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
a --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
using the failed result type. As of v2.0.0, we follow the lead of Cucumber-JS and use a
separate 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

Formatter interface

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.
Using 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

See CHANGELOG.md.