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.
Please read the CHANGELOG from Cucumber Core.
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 Option
s so that you don't have to deal with null
anyway.
All Cucumber Scala classes are now under io.cucumber.scala
package instead of cucumber.api.scala
.
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 typeString
. 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
}
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.
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.
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.