Skip to content

Latest commit

 

History

History
135 lines (102 loc) · 5.93 KB

v2.0.0.md

File metadata and controls

135 lines (102 loc) · 5.93 KB
Raw
layout nav date title author
post
blog
2017-08-29 09:00:00
Announcing Cucumber-JVM v2.0.0
brasmusson

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.