This version supports the usage of ScenarioContext variables for all URI parameters.

Now it is allowed to write sentences like:

Scenario: Use dynamic URL
  Given that the context contains the following 'key' and 'value' pairs
    | ${MY_DYNAMIC_URL} | https://google.com |
  And that the API path is "${MY_DYNAMIC_URL}"

Support for polling APIs

The polling configuration is automatically reset before each scenario.
It can be configured via the background or directly in the scenario.

When the expected HTTP status code and JSON structure has been sent as a response, polling will stop.
This allows an endpoint to be polled until it changes state or fail if the state has not changed during the specified time and retry configuration.

The configuration can be done in to ways.

As a single line configuration:

Scenario: Single line configuration
    Given that a request polls every 1 seconds for 5 times

Or as a multiline configuration that supports to specify one of the configurations in the Background and the other in the Scenario (or to have it more readable).

Scenario: Multiline configuration
    Given that a requests polls every 1 seconds
    And that a requests polls for 5 times

The URL/URI and (if required) body have to be preconfigured. Polling itself does simply use previous set body and path definition.
To execute a request it supports the well known authorized and unauthorized phrases and it supports direct JSON or JSON from file:

Authorized request with JSON response file:

Scenario: Authorized request with JSON response file
  Given that a request polls every 1 seconds for 5 times
  And that the API path is "/api/v1/polling"
  When executing an authorized GET poll request until the response code is 200 and the body is equal to file "expected.json"

Unauthorized request with JSON response file:

Scenario: Unauthorized request with JSON response file
  Given that a request polls every 1 seconds for 5 times
  And that the API path is "/api/v1/polling"
  When executing a GET poll request until the response code is 200 and the body is equal to file "expected.json"

Authorized request with direct JSON response:

Scenario: Authorized request with JSON response file
  Given that a request polls every 1 seconds for 5 times
  And that the API path is "/api/v1/polling"
  When executing an authorized GET poll request until the response code is 200 and the body is equal to
    """
    {
      "message": "SUCCESSFUL"
    }
    """

Unauthorized request with direct JSON response:

Scenario: Unauthorized request with JSON response file
  Given that a request polls every 1 seconds for 5 times
  And that the API path is "/api/v1/polling"
  When executing a GET poll request until the response code is 200 and the body is equal to
    """
    {
      "message": "SUCCESSFUL"
    }
    """

Examples can be found at src/test/resources/features/polling/.

This release updates the following libraries:

• Liquibase 3.10.3
• Kotlin 1.4.31

It also removes the Spring BOM, because the plugin should be enough.

This version introduces support for applications that do not have a database.
To configure the library to run database-less, it is necessary to set up the following configuration in the application.yaml file:

application.properties:

cucumberTest.databaseless=true

or

application.yaml:

cucumberTest:
  databaseless: true

If the databaseless key is not true or missing, the library tries to instantiate the database related beans.

In some cases it is required to disable the database autoconfiguration of Spring Boot:

application.properties:

spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration, org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration

or

application.yaml:

spring:
  autoconfigure:
    exclude: org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration, org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration

or as annotation:

@EnableAutoConfiguration(exclude = {DataSourceAutoConfiguration.class, DataSourceTransactionManagerAutoConfiguration.class, HibernateJpaAutoConfiguration.class})
@SpringBootApplication
public class Application {
  public static void main (String[] args) {
    ApplicationContext ctx = SpringApplication.run(Application.class, args);
  }
}

Please also make sure that the @ContextConfiguration annotation does not contain the DatabaseExecutorService.class.

Proxy support

This can be useful to use the cucumber tests together with burp-scanner.

The proxy can be configured with:

application.properties:

cucumberTest.proxy.host=localhost
cucumberTest.proxy.port=8866

or

application.yaml:

cucumberTest:
  proxy:
    host: localhost
    port: 8866

The host can be an IP or a domain. The port must be higher than 0.
If a condition is not met, the proxy is not set.

Default is deactivated.

Disable SSL verification

Along with proxy support, it may be necessary to disable SSL validation as well.

This can be configured via:

application.properties:

cucumberTest.ssl.disableCheck=true

or

application.yaml:

cucumberTest:
  ssl:
    disableCheck: true

Default is false.

Code changes

The Java code was refactored to Kotlin.
This should make the code more robust and better maintainable.

Enhanced tests

Tests for the database features were added under src/test/resources/features/database/.

Small bugfix release for proper mismatch messages of the matchers.

Small bugfix release for proper mismatch messages of the matchers.

Validate execution time of requests

Scenario:
  Then I ensure that the execution time is less than {long} ms

Validates, that the execution of the Scenario has taken less than [n] ms.

Please have a look to the examples at: src/test/resources/features/performance/.

Dependency updates

This release updates some dependencies.

Set the Bearer token dynamically

To be able to set dynamic bearer token, the following sentence can be used:

Feature: Bearer Token
  Scenario: Set bearer token directly
    Given that the Bearer token is "abcdefg"

This sentence is primarily looking into the context map if there is a key with the given value.
If this is not the case, it uses the given string directly as the token.

Please have a look to the examples at: src/test/resources/features/header/

The BddCucumberDateTimeFormat for custom date/time formatters has been changed from List<String> with a list
of patterns as string to List<DateTimeFormatter>.

Dependencies

Update of dependencies and Cucumber library 6.8.1.

Add own patterns for ${json-unit.matches:isValidDate}

To add own DateTimeFormatter patterns to extend the ${json-unit.matches:isValidDate} range
a new class is required that implements the interface BddCucumberDateTimeFormat.
The method pattern() must return the date patterns as List<String>.

To register this custom class it is necessary to add it @ContextConfiguration classes definition.

Example:

• Configuration context
• Test feature

This release only adds a date format for some databases.

The relative file paths and the absolutePath: keyword are now also valid for loading liquibase scripts.

The executor of the Liquibase scripts has sometimes problems with H2 memory databases, that the H2 connection is closed after the JDBC connection is closed.

This problem can now be solved by setting the following properties:

cucumberTest.liquibase.closeConnection=false

or

cucumberTest:
    liquibase:
      closeConnection: false

The default value is false, which means, that the connection will not be closed.

Adds support to define the target server, if the test library should be used for various tests in an outsourced test repository.

It is now possible to overwrite the protocol, host and port in the application.yaml/application.properties:

application.properties:

cucumberTest.server.protocol=http
cucumberTest.server.host=localhost
cucumberTest.server.port=80

or

application.yaml:

cucumberTest:
    server:
      protocol: "http"
      host: "localhost"
      port: 80

All parameters are optional. If nothing is being defined, it uses the default http://localhost:<LocalServerPort>.

This release fixes the problem, that the sentence to set a header value does not resolve the value first from the context.

Now it is possible to use static values or (if the value matches to the context) previously stored parameters.

Example:

src/test/resources/features/header/

The REST template has thrown an exception in case of 5xx response codes.

This version fixes the issue and returns the correct HTTP code and message.

Introducing user

With the following sentence it is possible to define multiple users:

Feature: User features
  Background:
    Given that the following users and tokens are existing
    | john_doe    | my_auth_token_for_john_doe    |
    | johana_doe  | my_auth_token_for_johana_doen |

Now every scenario in this feature can use the user with:

  Scenario: Using authorized user john_doe
    Given that the user is "john_doe"

The library selects the right token from the given list and executes the calls with this user.
It is also possible to define both in the Background specification. Then all tests will have this user as default:

Feature: User features in global context
  Background:
    Given that the following users and tokens are existing
    | john_doe    | my_auth_token_for_john_doe    |
    And that the user is "john_doe"

Please have a look to the examples at: src/test/resources/features/user/

Fewer sentences but still compatible and more possibilities

This release introduces the parameter {httpMethod} which replaces all sentences with an HTTP method in the name.
Allowed values are:

• GET
• POST
• DELETE
• PUT
• PATCH

This reduces the number of Gherkin sentences by 24 and adds 24 new possible sentences because the shorter GET sentences are now also available for all other methods.

Validate only special fields of the response body

Validation of one field

  Scenario: Validate field of the body
    Then I ensure that the body of the response contains a field "list[0]" with the value "First"
    And I ensure that the body of the response contains a field "$.list[1]" with the value "Second"
    Then I ensure that the body of the response contains a field "shouldNotExist" with the value "@bdd_lib_not_exist"

Validation of multiple fields

  Scenario: Validate multiple fields
    And I ensure that the body of the response contains the following fields and values
    | string           | is a string                 |
    | number           | 12                          |
    | uuid             | ${json-unit.matches:isUUID} |
    | $.number         | @bdd_lib_not 15             |
    | list             | ["First","Second"]          |
    | list[0]          | First                       |
    | $.list[0]        | BDD_TEST_LIST_FIRST_ELEMENT |
    | $.list[1]        | Second                      |
    | object.firstname | John                        |
    | object.lastname  | Doe                         |
    | shouldNotExist   | @bdd_lib_not_exist          |

In this case, the fields that should be compared can be given as a data table map.
The first column is the field name, the second the expected value.

Description

This sentence compares only the given field of the response.
The field can be a JSON path. The library checks if it starts with $..
If it does not start with $. it will be added internally.

To test if a field is NOT present, the reserved word @bdd_lib_not_exist can be used as the value.

To test if a value is NOT the expected value, the reserved word @bdd_lib_not can be used to negate the comparison.
It is not possible to use a ! as a negation prefix, because it can also be a valid result.

The library also tries to resolve the value from the context map.
If nothing was found, the original value is used.

It is also possible to use JSON-Matcher (user-defined and bdd-cucumber-lib).
These are written with the notation ${json-unit.matches:isUUID} (as an example for the UUID-Matcher).

ATTENTION: Only unparameterized custom matchers or bdd lib-matchers can be used for field validation!

Find examples for this feature under: src/test/resources/features/body_validation/.

Reset the scenario context

Scenario: Reset the scenario context
    Given that the stored data in the scenario context map has been reset

Reset the context state map.