Skip to content

Latest commit

 

History

History
83 lines (55 loc) · 3.02 KB

upgrade_v5.md

File metadata and controls

83 lines (55 loc) · 3.02 KB

Upgrading from 4.x to 5.x

If you are using Cucumber Scala 4.7.x and want to upgrade to 5.x, please note there are some major changes in addition to the Cucumber upgrade itself.

Starting from version 5.x, Cucumber Scala will try to be as close as possible to the Cucumber Java implementation while remaining Scala oriented. This means that package names, parameters order, internal code... will be more consistent with the Java implementation.

Cucumber Core changes

Please read the CHANGELOG from Cucumber Core.

Empty values in Datatables

Starting with Cucumber 5.x, empty values in Datatables are now represented as null instead of an empty string previously.

Check out the Empty values section in Transformers documentation to learn how to have empty values in your Datatables.

You can also consider upgrading to Cucumber Scala 6.x straight away as Cucumber Scala 6.x provides a way to map Datatables as collections of Options so that you don't have to deal with null anyway.

Packages

All Cucumber Scala classes are now under io.cucumber.scala package instead of cucumber.api.scala.

Hooks

The Before, BeforeStep, After and AfterStep definitions have slightly changed:

  • to apply only to scenarios with some tags, the String* parameter is replaced by a single tag expression of type String. This changes comes from Cucumber itself.
  • if providing both an order and a tag expression, the order is now the second parameter instead of the first. This is more consistent with the Java implementation.

For instance, the following code:

Before(1, "@tag1", "@tag2") { _ =>
  // Do Something    
}

Is replaced by:

Before("@tag1 or @tag2", 1) { _ =>
  // Do Something    
}

Other changes

As a side effect the following usage no longer compiles:

Before() { _ =>
  // Do something
}

It can be replaced with:

Before { _ =>
  // Do something
}

See also the Hooks documentation.

Transformers

If you are using transformers defined with TypeRegistryConfigurer, please note that this is now deprecated in Cucumber Core.

The recommended way to define transformers is to define them in glue code. See Transformers.

Under the hood

Instantiate glue classes per scenario

Before Cucumber Scala 5.x, glue classes (classes extending ScalaDsl) were instantiated only once for a test suite.

This means that if you wanted to keep state between steps of your scenarios, you had to make sure the state was not shared to other scenarios by using hooks or manual checks.

Starting from Cucumber Scala 5.x, each scenario creates new glue class instances.

You should not notice any change unless you rely on state kept between scenarios in your glue classes. Please note that this is not the proper way to keep a state. You might want to use an object for this purpose.