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 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.
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
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, 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.
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. Expressions like
--tags 'not @foo or @bar' or
Before("@foo and @bar") can therefore be used. The old syntax for "not" (
[email protected]) 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
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