BlueVibes test suite

(version 0.5.0)

1. Introduction

BlueVibes test suite is a collection of testing modules, which allow easier testing of cloud-native applications, with special focus on Blue Vibes applications and BV Container.

1.1. Module overview

The BlueVibes test suite will contain multiple modules. You may include only one or several modules.
At the moment, we have implemented e2e module.

1.1.1. E2E

E2E is a part of test suite that deals with end-to-end testing, with user perspective (GUI) in focus.
It is a toolset for developers primarily, however, generated reports can be understood by anyone as these are in plain English.
BlueVibes e2e aims to provide a mechanism for easy writing of an e2e test, with main goals:

To achieve these goals, the module combines the best of:

and does so by wiring JGiven, TestContainers, Selenium and Blue Vibes together in one powerful toolset.

2. Installation

The library is installed as any other Java library by adding JAR file(s) into the project classpath. Usually, it is done by using Maven or Gradle.

2.1. Dependency management

Since bv-test-suite aims to provide multiple modules which can be used separately, in order to avoid conflict with the different versions, it is good practice to use dependency management, but it is not mandatory.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.bluevibes</groupId>
            <artifactId>bv-test-suite</artifactId>
            <version>0.5.0</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>

2.2. Adding bv-e2e

To add e2e module following has to be added to POM:

<dependency>
    <groupId>io.bluevibes</groupId>
    <artifactId>bv-e2e</artifactId>
    <scope>test</scope>
</dependency>

(!) Notice: if the <dependencyManagement> mentioned above is not configured, the version of bv-e2e must be provided here.

2.3. Plugin dependencies

The test suite is built on top of JUnit5 and JGiven and they require certain plugins in order to work. So those plugin dependencies should be added into plugins:

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
            <systemPropertyVariables>
                <jgiven.report.dir>/data/jenkins/jenkins-data/jobs/Infra_Release/workspace/docs/target/jgiven-reports/json</jgiven.report.dir>
            </systemPropertyVariables>
        </configuration>
    </plugin>
    <plugin>
        <groupId>com.tngtech.jgiven</groupId>
        <artifactId>jgiven-maven-plugin</artifactId>
        <executions>
            <execution>
                <phase>test</phase>
                <goals>
                    <goal>report</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <format>html</format>
            <title>Blue Vibes Test Suite Report</title>
        </configuration>
    </plugin>
</plugins>

In example above versions of plugins are not specified, it is supposed that pluginManagement is defined in the parent pom. So if the plugin management is not defined, it could be done by adding following:

<pluginManagement>
    <plugins>
       <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.7.0</version>
            <configuration>
                <!-- java.version: 1.8+ -->
                <source>1.8.0_242</source>
                <target>1.8.0_242</target>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <!-- surfire.plugin.version: 2.19.1 or higher -->
            <version>2.19.1</version>
            <dependencies>
                <dependency>
                    <groupId>org.junit.platform</groupId>
                    <artifactId>junit-platform-surefire-provider</artifactId>            
                    <!-- junit.platform.version: 1.1.0 or higher -->
                    <version>1.1.0</version>
                </dependency>
                <dependency>
                    <groupId>org.junit.jupiter</groupId>
                    <artifactId>junit-jupiter-engine</artifactId>
                    <!-- junit.jupiter.version: 5.1.0 or higher -->
                    <version>5.1.0</version>
                </dependency>
            </dependencies>
        </plugin>
        <plugin>
            <groupId>com.tngtech.jgiven</groupId>
            <artifactId>jgiven-maven-plugin</artifactId>
            <!-- jgiven.maven.plugin.version: 0.18.2 or higher  -->
            <version>0.18.2</version>
        </plugin>
    </plugins>
</pluginManagement>

3. Getting started

Once the dependency is configured, the next step is writing test classes.

3.1. Writing e2e test class

First of all an e2e class has to be annotated by org.junit.jupiter.api.extension.ExtendWith and it should extend io.bluevibes.testsuite.e2e.BaseE2eTest:

import com.tngtech.jgiven.junit5.JGivenExtension;
import io.bluevibes.testsuite.e2e.BvContainerE2eTest;
import io.bluevibes.testsuite.e2e.core.TestEnv;
import org.junit.jupiter.api.extension.ExtendWith;

@ExtendWith(JGivenExtension.class)
public class MyTest extends BaseE2eTest<TestEnv> {
    
}

The BaseE2eTest requires 1 type parameter, and it represents a test environment configuration. Out of the box TestEnv is provided by bv-e2e and it contains commonly used properties, but it can be extended and customized.

3.2. Writing a scenario

First of all the stages has to be defined, in this simple test only WhenGuiUser and ThenGui are used. Test class could extend BaseGuiTest so the mentioned stages would be provided out of the box. The next step is writing a test method. Usually, one test method represents one scenario case. Example:

import com.tngtech.jgiven.annotation.ScenarioStage;
import com.tngtech.jgiven.junit5.JGivenExtension;
import io.bluevibes.testsuite.e2e.BaseE2eTest;
import io.bluevibes.testsuite.e2e.core.TestEnv;
import io.bluevibes.testsuite.e2e.then.ThenGui;
import io.bluevibes.testsuite.e2e.when.WhenGuiUser;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;

@ExtendWith(JGivenExtension.class)
public class MyTest extends BaseE2eTest<TestEnv> {

    @ScenarioStage
    protected WhenGuiUser<?> user;

    @ScenarioStage
    protected ThenGui<?> gui;

    @Test
    void chrome_urls_are_listed() {
        user.when()
                .navigate_to_url("chrome://chrome-urls/");

        gui.then()
                .has_label_$("List of Chrome URLs")
                .and().user_can_choose_between_$_options("chrome://about", "chrome://apps", "chrome://help");
    }
}

3.3. Default environment properties

The default test environment file (e2e.yml) is required and must be present in the classpath. In this example, it is not used, because the example is really simple. So an empty e2e.yml has to be placed into src/test/resources. Using and purpose of environment configuration are described below.

3.4. Running the scenario

The scenario can be executed like any other JUnit test by using IDE or Maven:

$ mvn clean test

After execution, the following report will appear in the console:

Test Class: MyTest

 Chrome urls are listed

   When navigate to url chrome://chrome-urls/
   Then has label "List of Chrome URLs"
    And user can choose between chrome://about, chrome://apps, chrome://help options

4. Reporting

4.1. Generation

The reporting is based on JGiven reporting, so by default scenario reports will be printed in the console. Besides that, when the configuration is as described, an HTML report will be generated. But in a case when the test phase fails, the HTML report has to be generated by running $ mvn jgiven:report. Once the HTML report is generated, it can be accessed by the browser on the following path: ${E2E_PROJECT_HOME}/target/jgiven-reports/html/index.html. More about JGiven reports.

4.2. Known issues

Currently, there is an issue in JGiven reporting: attachments in nested steps. The issue is present only in HTML report, even if an attachment is present in JSON report, it doesn’t appear in HTML report. More about it on JGiven github.

5. Test environment configuration

One of the main goals is to accomplish motto “write once, run anywhere”, to make test usable on different test environments i.e. local, dev, UAT, etc. To make it simple we have introduced configuration per environment.

5.1. Defining environment properties

First of all, to reuse a test in different environments, the test should not contain any environment-specific properties.
All those properties should be defined per environment. To simplify the handling of those properties, we have introduced yaml configuration files per environment. The default properties that are relevant to all environments should be kept in e2e.yaml. Env-specific properties should be defined in files with naming convention e2e-ENV_NAME.yml. Which properties will be applied depends on the system property bv.testsuite.environment. This property can be set as a command-line argument or even better approach would be using maven profiles.

5.2. Accessing environment properties

Every E2E test that extends BaseE2eTest will automatically load desired environment properties, and they are accessible by protected property env of type TestEnv. TestEnv contains many of fields(props) that are automatically used by provided given, when and then stages, those properties are described bellow depends where they are used. Besides that, there is a general-purpose property custom-props which represents a map of custom properties. Supported map values are int, double and String. For all other types of value will be deserialized to String, so it can be parsed to eager type by the developer.

Example :

custom-props:
  intValue: 1
  doubleValue: 1.0
  stringValue: xyz

usage in test:

int intValue = (int) env.getCustomProps().get("intValue");
double doubleValue = (double) env.getCustomProps().get("doubleValue");
String stringValue = (String) env.getCustomProps().get("stringValue");

5.3. Different environments

As it is described above in the case of multiple environments common props should be kept in e2e.yml, and all other in environment-specific files. So let’s imagine a case with two environments local(default) and UAT. There will be two files:

e2e.yml

custom-props:
  message: "hello from %"
  name: "local machine"

e2e-UAT.yml

custom-props:
  name: "UAT ENV"

To run the test in default environment test should be run as usual $ mvn test, and if props are accessed in the test they will have values “hello from” and “local machine”. For running the test with UAT props, the property bv.testsuite.environment should be provided, it can be done by configuring maven/gradle or defining in IDE. Or simply by calling the command: $ mvn test -Dbv.testsuite.environment=UAT. When test is run for UAT environment the value of message will be “hello from %”, because it is the default profile, and the value of the name will be “UAT ENV”.

5.4. Extending TestEnv

Using custom-props could be a little bit chaotic in cases when there is a need for many variables or in the case when those variables require a specific type (not only string or number). To overcome this problem, the custom class can be created. The custom class has to extend TestEnv, i.e.

public class MyTestEnv extends TestEnv {
    
    @JsonMerge
    private MyMessage myMessage;
}

Additionally the test class has to extend base class with proper generics BvContainerE2eTest<MyTestEnv> or BaseE2eTest<MyTestEnv>, for example:

@ExtendWith(JGivenExtension.class)
public class MyTest extends BvContainerE2eTest<MyTestEnv> {
    
    @Test
    void chrome_url_are_listed() {
        // omitted code ...
        
        then()
                .has_label_$(env.getMyMessage().getFormatedMessage());
    }
}

6. Test scenario

A scenario consists of multiple stages. Usually there is a stage for each phase of a scenario:

In order to avoid boilerplate code and speedup writing test, there are a few base test classes with predefined stages (given/when/then) that should be used as a super class:

6.1. Given: set up a system

Usually, e2e tests can be performed against an online system as well as a local docker system. The local system should be similar to the online system as far as possible. In order to make tests reusable on a local and online system, the framework provides given stages that set up a local docker system and reusing that given stages later for online. There are two prebuilt given stages which can be used in an e2e test:

6.1.1. Docker compose setup

This way is preferable especially in case when a docker-compose.yml is present in project or when setup is complex and requires many docker containers. Depends on it which class is used as base class for test, method given() will return GivenSystem or GivenBvc, nevertheless which one is returned setup is the same:

given()
    .a_system( setup -> setup.compose()
                        .default_docker_compose()
                        .and().it_is_started()
            );

To make this code work, the path to the docker-compose.yml has to be defined in the configuration. To do that the following configuration has to be defined in e2e.yml:

# e2e.yml
docker:
  docker-compose:
    file-path: src/test/resources/docker-compose/docker-compose-test.yml # insert you path

Regarding the docker-compose.yml, there are some limitations that the developers have to be aware:

# docker-compose.yml
networks:
  default:
    external:
      name: bv-test-suite-network
# e2e.yml
docker:
  docker-compose:
    file-path: src/test/resources/docker-compose/docker-compose-test.yml
    env-variables:
          compose: true
          BV_CONTAINER_IMAGE: docker.corp.ametiq.com/bv-container
          BV_CONTAINER_IMAGE_TAG: 5.2.0
          BV_CONTAINER_BASE_URL: https://apache-proxy/bv/dev

Since starting a docker-compose takes time, in order to make test execution more time-efficient, by default test will start docker-compose once and it will keep it running until all scenarios are done. In some cases when the stage of a container is dirty (i.e. delete, diff. configuration, etc), it could cause tests failing, so to force restarting containers for every scenario the flag is_dirty has to be set. It can be done directly in scenario code by given step method it_$_dirty(true).

6.1.2. Programmatic docker setup

In case when we are testing one or several applications and its integration especially with BVC, this approach of setup is more suitable than compose. Depending on which class is used as based class for the test, method given() will return GivenSystem or GivenBvc, regardless of which one, the setup is similar. The focus here is on GivenBvc:

given()
        .a_system(setup ->
                setup.programmatic()
                        .micro_app_$("bva-complex-tutorial")
                        .and().component_$("movies-control-panel")
                        .and().BV_container()
                        .and().active_spring_profile("dev")
                        .and().default_workspace()
                        .with().instance_of_micro_app_$_and_component_$("bva-complex-tutorial", "movies-control-panel")
                        .and().page_$_containing_last_added_instance("Test")
                        .and().it_is_started()
                        );

So this part of code will setup system where micro-app “bva-complex-tutorial” is running inside of BVC with the default workspace and a page that displays the micro-app component. Of course, there is a possibility to register multiple micro-apps and create multiple workspaces and pages. Beside writing given scenario, to make this part of test runnable, the following configuration has to be provided:

docker:
  programmatic:
    bv-container:
      tag: 5.2.0
    containers:
      bva-complex-tutorial:
        docker-image: docker.corp.ametiq.com/bva-complex-tutorial
        tag: 0.2.0
        port: 60002

This configuration provides basic information about images that are used in the setup. The configuration is not required, this information can be provided directly in the code of the scenario. This could make the scenario a bit more complex, though.

Besides those steps from the example above, there are a few other methods that could be used, depending on the requirements. Since every step builds the system state, the order of steps can be important. When steps are not in right order an exception with the message which step is expected to be executed before the current will be thrown.

Similar to compose, in order to improve time efficiency, docker containers will be started after the first execution of given stage and they will keep running after all scenarios are done. But here is a small difference when a certain container requires a restart because of the dirty state, exactly that container can be marked as dirty. So only this container will be restarted between scenarios. This flagging can be done by configuration, i.e.:

# e2e.yml
docker:
  programmatic:
    containers:
      a-dirty-container:
        dirty: true

Or it can be done directly in scenario code:

 setup.programmatic()
            .with().micro_app_$("a-dirty-container")
            .and().it_$_dirty(true)
            ...

(!) Having one or more dirty containers can slow down test significantly, so use them only when it is necessary.

6.1.3. Online

A scenario-based on docker setup (compose or programmatic) beside local dev machine and jenkins is executable against an online(deployed) system too. Since an online system is already deployed and there is no need to start the environment using docker containers again, to prevent the running of Docker containers, a configuration has to be provided for the target environment (i.e. e2e-int.yml) with the following properties:

use-containers: false # prevents starting docker containers 
base-url: https://banking-offsite.ametiq.com/demo/ # tells where the online system is deployed

(!) The property use-containers is affects only given system containers, and it doesn’t have an impact on other containers (i.e. Selenium test containers)

6.1.4. Customization and extending

In case when there is more than one scenario and class using the same docker setup, it is good idea to extract the setup in a static method so it can be referred in all scenarios/classes i.e.:

public final class DockerSetup {
    public static void composeSetup(GivenBvc<?> setup) {
        setup.compose()
                .with().default_docker_compose()
                .and().it_is_started();
    }
}

//Test class
@Test
void docker_compose_http_smoke_test() {
    givenBvc.given()
            .a_system(DockerSetup::composeSetup);
    
    // ...
}

Another approach to reuse steps or create more reusable stages is extending those provided stages and adding methods that are more suitable for a certain project. Beside the provided scenario any additional given stage can be created and used inside of the test. But during the design of that stage, the developer has to keep in mind that stage and scenario should be reusable in different environments.

6.2. When: actions

A when stage contains actions that could be performed in a system. Since accent is on the e2e testing the framework offers two type of when stages (actions) : WhenGuiUser (GUI) and WhenRest (REST Api).

6.2.1. GUI action

Gui testing is based on Selenium and testcontainers and it uses a remote driver for accessing browser in testcontainers. The Selenium container is always started when a test has WhenGuiUser. Another important component is ElementFinder which is used by WhenGuiUser and relies on Selenium, but instead of using strict CSS/XPath element finding, it uses heuristics for finding elements. It allows writing steps that are more close to natural language.

The test device

Since the framework relies on the Selenium, the developer can choose between Chrome and Firefox. The default browser is chrome. Since the change browser requires a reset of containers, the only way to change the browser is through the configuration property device.browser. So it means if the same test should be performed in chrome and firefox, addition profile configuration e2e-firefox.yml has to be created. Unfortunately, this approach is not so convenient, especially in the case when there are multiple test environments, every environment file has to be duplicated.

Besides browser type, the screen size of the test device can be changed, the default size is 1920x1080. Screen size for all tests can be changed in the configuration:

# e2e.yml
device:
  screen-resolution:
    width: 600
    height: 800

But since the changing size doesn’t require a reset of selenium, the size can be changed directly by calling the following step WhenGuiUser::resize_screen_to_$_x_$_px(width, height). This approach is very helpful when responsive design and resizing handling have to be tested.

Loading time

Depending on where tests are executed, the loading and rendering time can vary, which can cause some tests to falsely fail due to late rendering. The default timeout for waiting on a page to be loaded and rendered in 15 seconds. The timeout could be decreased in order to improve test execution time or increased to prevent tests failing because of a slow environment. It can be done in the configuration:

device:
  patience-timeout-in-seconds: 60
Browser action

Every GUI test has to start with navigation to the test system URL, for that purpose, WhenGuiUser method navigate_to_url() has to be used. Depends on the test environment it navigates the browser to BVC docker address in case of local/jenkins test or to the base-url in case of an online system. Additionally there is step with URL argument navigate_to_url(url) that navigates the browser to the URL.

Beside that WhenGuiUser offers a few standard browser actions:

Interaction with the application

The main interaction a GUI user with the application are clicking on button and filing inputs. So WhenGuiUser provides step methods for those actions:

Similar to a real user, the test should wait on some events like the page to be loaded or when something is deleted wait on it to disappear from the page. To support that the following methods are available in WhenGuiUser stage:

Authorization

Considering that the local system usually does not require login as well as that the session will be kept by selenium, so login will be needed only in the first test, WhenGuiUser stages offer method login_as_$_if_needed(user). So this method performs login, only if it is needed and does not fail if the login form does not appear. The argument user represents the key for user credentials from the configuration. For example, if we have the following configuration:

# e2e.yml
  
user-credentials:
  test:
    username: demo
    password: xyz
  admin:
    username: admin
    password: 321
  moderator:
      username: max
      password: 321  

And in test we use following step:

when()
   .login_as_$_if_needed("test")
   ...

It pickups user name “demo” and password “xyz” , fills login form with them and perform login, so the user will be logged in the system as “demo” user.

Since user names and passwords are usually different for different test environments, they should be provided in the configuration for the certain test environment, i.e. credentials from the example above for UAT:

e2e-UAT.yml
user-credentials:
  test:
    username: ametiq
    password: 54321
  admin:
    username: root
    password: "#$##$"
  moderator:
      username: mod
      password: qawswed

So when tests are performed against a test system, the proper credentials will be used for logging.

6.2.2. Rest actions

6.2.3. Customization and extension

There are two main reasons when a developer should not use provided when steps directly in the test:

The first problem does not necessary require extending when stages, the wrapping technical details can be done by calling method does_it(stepBusinessLabel, lambdaSteps). And then report will contain business label with nested technical steps. For example the following part of code:

when()
   .does_it( "delete accont", 
        self -> self.click_on_$("delete")
                    .and().click_on_$("save")
                    );

will generate a report:

> When delete account
    click on delete
    And click on save

By default nested step are collapsed, so when business people are reading reports do not need to bother with technical details, but if they are interested in it, they can expand the nested step an see what exactly it does.

The second problem (DRY) could be solved by combining the method does_it and static creating method that will be used as lambda steps. This approach is suitable when there are a few methods that should be reused. In case if there are many steps, a more convenient approach would be creating new when-class which extends WhenGuiUser or WhenRest.

6.3. Then: verification

When an action is performed, the next step is verification that the result of the action is expected. To make verification easier, the test suite offers two prebuilt stages: ThenGui and ThenRest. Depends on test superclass one of these stages will be available under then() method.

6.3.1. Gui verification

After an action, the verification is the result as expected can be done in two way:

DOM verification

This approach proves that action as triggered and the result elements are present in the DOM. And it is helpful because it is simple and fast. There are a few methods provided by ThenGui that should be used for this verification:

Visual verification

Unfortunately, the presence in the DOM does not mean necessarily that a component is correctly rendered and well looking. For that purpose visual verification should be used. Currently, there are a few steps that could be used for that purpose:

Other verification

Beside above mentioned verifications, there is a few verifications that could be done regarding browser states:

6.3.2. REST API verification

6.3.3. Extending and customization

Test developer should not use provided when steps directly in a test, in the following cases:

The first problem does not necessary require extending then stages, the wrapping technical details can be done by calling method it(stepBusinessLabel, lambdaSteps). And then report will contain business label with nested technical steps. For example the following part of code:

then()
   .it( "has active accont", 
        self -> self.has_label_$("115-002920-20")
                    .and().has_label_$("Active")
                    );

will generate a report:

> Then has active account
    has label "115-002920-20"
    And has label "Active"

By default nested step are collapsed, so when business people are reading reports do not need to bother with technical details, but if they are interested in it, they can expand the nested step and see details.

The problems DRY and a custom selector could be solved by combining the method it and static creating method that will be used as lambda steps. This approach is suitable when there are a few methods that should be reused. In case if there are many steps, a more convenient approach would be creating new when-class which extends ThenGui or ThenRest.

6.4. Element finder

Another important component of e2e and GUI testing is the elements finder ElementFinder. This component is used by both WhenGuiUser and ThenGui stages for finding elements on a page. The implementation tends to be smart and to use a heuristic approach for element searching. Instead of the traditional approach of passing exact CSS/XPath query as arguments for element searching, it expects just a short term witch best describes the target element, and it should be readable in the report. The term is interpreted by ElementFinder, so elements that best match the term would be returned. The term is usually a case sensitive text, which is contained in one of the following: displayed text, element id, name, icon name, CSS class, etc. Following examples should give a better overview and understanding:

7. Appendix A: Test environment properties

This appendix provides a list of common test suite properties and references to the underlying classes that consume them. Here is an example of configuration (e2e.yml) file with all properties:

# General 
use-containers: true
base-url: http://bv-container:8080
network-name: bv-test-suite-network

# docker test containers  
docker:
  startup-timeout-in-seconds: 300
  programmatic:
    bv-container:
      tag: 5.3.0
      dirty: false
    containers:
      bva-complex-tutorial:
        docker-image: docker.corp.ametiq.com/bva-complex-tutorial
        tag: 0.2.0
        port: 60002
        dirty: false 
  docker-compose:
    file-path: "src/test/resources/docker-compose/docker-compose-test.yml"
    exposed-service-name: bv-container
    exposed-service-port: 8080
    env-variables:
      BV_CONTAINER_IMAGE: docker.corp.ametiq.com/bv-container
      BV_CONTAINER_IMAGE_TAG: 4.1.3

# Test device 
device:
  browser: chrome
  patience-timeout-in-seconds: 5 
  screen-resolution:
      width: 600
      height: 800
# Scenario properties  
user-credentials:
  test:
    username: demo
    password: xyz
  admin:
    username: admin
    password: test

translation:
  key.example:
    de_CH: xyz
    en_US: zyx

custom-props:
  intValue: 1
  doubleValue: 1.0
  stringValue: xyz

7.1. General overview

property type description default required
use-containers boolean Tells should a test start docker with given system containers. true No - the default will be used
base-url String Represents Base URL which Selenium will use to test the GUI. It would be generated, when the system setup is local docker Yes - when test is online
network-name String Name of the docker network that will be created if not found. The network is always used, irregardless of whether docker mode is used. Internally, docker is always used (Selenium runs inside docker). bv-test-suite-network No - the default will be used
docker Docker Provides necessary information needed for setup system with local docker. Yes - when use-containers=true, otherwise No.
device Device Represents settings of the test device in selenium. Chrome browser(FullHD), more details in Device No - the default will be used
user-credentials Map<String, Credentials> Map of user credentials needed for the login process. empty map No
translation Map<String, Map<String, String>> Represents a map where a key is translation key and value is another map of translation for the key per language. empty map No
custom-props Map<String, String/int/double> Represents a map of scenario custom properties. empty map No

7.2. Docker properties

property type description default required
startup-timeout-in-seconds int Represents timeout in seconds that test setup will wait for docker container to startup. 300 No - the default will be used
programmatic Programmatic Provides necessary information about docker images that are used for programmatic setup of a test system. Yes - when test use a programmatic setup
docker-compose DockerCompose Provides necessary information for running a docker-compose setup. Yes - when test use a docker-compose setup

7.2.1 Programmatic setup

property type description default required
bv-container ContainerProps Basic information about the bv-container docker. Yes - when Bvc setup is used
containers Map<String, ContainerProps> Basic information about docker containers that are used in the programmatic setup. No

ContainerProps

property type description default required
docker-image String Desired docker image name. Yes
tag String Docker image tag. Yes
port int The service listening port. Yes
dirty boolean Indicates that the container has a dirty state, and has to be restarted before next scenario usage. false No - the default value will be used

7.2.2 Docker compose setup

property type description default required
file-path String Path to the docker-compose.yml that will be used for setup. src/test/resources/docker-compose-test.yml No - the default value will be used
exposed-service-name String Name of a service exposed as the main service. Yes
exposed-service-port int Port of a service exposed as the main service. Yes
env-variables Map<String, String> Map of environment variables are used by docker-compose. empty map No

7.3. Device properties

property type description default required
browser enum[CHROME,FIREFOX] Browser that will be used for testing. CHROME No - the default value will be used
patience-timeout-in-seconds int Defines how many seconds test “user” is ready to wait on an element to appear in the browser. 15 No - the default value will be used
screen-resolution ScreenResolution(width:int, height:int) Defines size of the screen that would be used for testing. FullHD(1920×1080px) No - the default value will be used

7.4. Credentials properties

property type description default required
username String Username for certain user and environment that will be used in the login process. No
password String Password for certain user and environment that will be used in the login process. No