Version: 7.0

Test Automation

Part of every development process is the test phase of the developed functionality. This principle should also be used in the area of automation and, as in all areas of development, is an important part of comparing the implementation with the requirements and confirming that the desired stability is still guaranteed.

The concept of testing covers a wide area. There are differences in quality, quantity and execution technique. The best4Automic modules in this category deal with test automation.

Cucumber

Cucumber is a behavior-driven development tool for the textual specification of software requirements and the automated checking of this description for correct implementation. This form of specification is used in the context of test automation to define test cases for workflows and execute them automatically.

A definition (a so-called feature) can consist of several scenarios. Each of these scenarios defines a test case. All scenarios in a feature are used to test the described functionality. A test case consists of three phases:

Given: Checking whether the environment meets expectations
When: Execution of the test steps
Then: Check the results of the test execution

Cucumber is a generic definition that is independent of various test procedures. For special use in the context of Automic Automation Engine, steps have been defined in best4Automic to specify test cases. These consist of the definition of corresponding sentences and the implementing implementations that perform the executions or checks. A unique key is used to assign the records to the implementations. The assignment is defined in the configuration file cucumber.conf. An example is supplied that defines a corresponding record for all existing implementations. The records are defined as regular expressions that define a precisely defined set of keywords in named groups for each implementation. Example:

when-execute = Execute +@OBJECT_NAME@(:? +on date @DATE@)?(?<parameters> +with parameters)?(?: +do not wait longer than @TIME@)?

The key when-execute defines a step that can activate objects in the Automic Automation Engine. A logical date can optionally be passed and/or a list of PromptSet parameters. The specified regular expression contains named groups object, date and parameters. The groups object and date are hidden in the predefined variables @OBJECT_NAME@ and @DATE@.

Examples of cucumber definitions that use these sets can be found in the examples directory of the distribution (Details).

Predefined regular expressions

@OBJECT_NAME@ - regular expression for object names that defines the object group
@ALIAS@ - regular expression for aliases that defines the alias group
@OBJECT_VARIABLE@ - regular expression for AE script variables that defines the variable group
@TASK_NAME@ - regular expression for tasks that defines the task group
@VARIABLE@ - regular expression for variables that are cached during test case execution that defines the attribute group
@REPORTTYPE@ - regular expression for report types that defines the reporttype group
@DATE@ - regular expression that recognizes a date of the form YYYY-MM-DD and defines the group date.
@TIME@ - regular expression that recognizes two different time formats. One is a timestamp of the form HH: MM:SS, which is defined as the group "time". Or relative time specifications of the form ([0-9]+h)?([0-9]+m)?([0-9]+s)? The individual parts are defined as groups hours, minutes and seconds.
@CONNECTION@ - regular expression for a b4A connection
@FOLDER@ - regular expression for a folder/path in a client

Formats

Cucumber itself specifies a text format for the definitions that are based on the syntax of Gherkin. An example looks like this.

Feature: Workflow to show a Cucumber example

    Scenario: Execute Masterworkflow with logical date and check preaggregate jobs
        Given Workflow PCK.BEST4AUTOMIC_CUCUMBER.JOBP.TEST with tasks
            |Tasks |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST1(2) |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST2(3) |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST3(4) |

        When Set values of variable PCK.BEST4AUTOMIC_CUCUMBER.VARA.SET_VALUES to
            |Key |Value 1 |
            |EMAIL |test-team@example.com |

        And Execute PCK.BEST4AUTOMIC_CUCUMBER.JOBP.TEST(TEST_RUN) on date %{DATE:-1d:} do not wait longer than 30m
            |key |value |
            |action# |add |
            |pattern# |* |

        And Remember &ticket_number# from PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST2(3) of TEST_RUN as incident-number

        Then Task status of TEST_RUN is
            |Task |Status |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST1(2) |ENDED_OK |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST2(3) |ANY_OK |
            |PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST3(4) |ENDED_OK |

        And Check if PCK.BEST4AUTOMIC_CUCUMBER.JOBP.CHECK_INCIDENT for TEST_RUN ended successfully
            |key |value |
            |incident_number# |%(incident-number) |

        And Comment of task PCK.BEST4AUTOMIC_CUCUMBER.JOBS.TEST1(2) of TEST_RUN contains '*test*'

If several scenarios are defined in a feature, the preconditions of the tests may be similar. Instead of repeating these for each scenario, the common preconditions can also be outsourced in a background definition within the feature.

Feature: Testing b4A modules



    Background: Given b4A options
        |Option |Value |
        |log-variants |REPORT |
        |log-flags |+MONOCHROME |
        |log-levels |+DEBUG |



    @tag1 @tag2
    Scenario: Check if b4A info.Search works and no translation is missing
        When Start b4A module info.Search
            |Parameter |Value |
            |connection |AE12-0010 |
            |folder |TESTS |
            |name |TEST* |



        Then Exitcode of b4A module info.Search is 0
        And Report of b4A module info.Search does not contain "![a-zA-Z.]+!"



    Scenario: Check if no translation is missing
        When Start b4A module info.Search
            |Parameter |Value |
            |help |true |
        Then Report of b4A module info.Search does not contain "![a-zA-Z.]+!"

It is also possible to mark scenarios and features with tags. Each tag must start with an @. If several tags are specified, they must be separated by spaces. If the tests are started with the b4A module ta.Execute, it is possible to pass a list of tags. In this case, only tests that have at least one of the specified tags are executed. Another option makes it possible to specify a list of tags that leads to the exclusion of tests. Here too, it is sufficient for a test to have one of the specified tags. During execution, the list of tags that allow tests is checked first and then the list of tags that lead to exclusion.

All b4A modules that deal with Cucumber can transfer Cucumber definitions into structured documentation on an object and, if necessary, also log the test results there. This structure is explained below.

b4A Expressions

In the test specifications, b4A expressions can be used to keep the definitions flexible. For example, times or dates can be specified as b4A expressions so that they are not correct at a single point in time, but adapt dynamically. The %{DATE::} and %{TIME::} functions can be used for this. The following attributes are also available:

b4A
- connection: Name of the b4A connections
- client: Number of the client used
- system: Name of the Automic Automation Engine system
- username: User name of the current connection
- department: Department of the current user
- timezone: Time zone of the current connection
- language: Language of the current connection
- version: Version number of the Automic Automation Engine

Example

Connection: %(b4A.connection)
System: %(b4A.system)
Client: %(b4A.client))

Logic during test processing

When executing the test cases, the entire test specification is read in first. The b4A expressions are replaced at runtime. Each test step in the test specification is mapped to one of the existing implementations. If no existing implementation is found for a test step, i.e. a record, the test specification is faulty. However, the import is not aborted. There is merely a note in the report. The scenarios are then processed step by step. If a scenario contains a faulty test specification, processing of the scenario is skipped. For such a scenario, the progress bar shows the number of successfully read test steps plus the incorrect one as failed. If the test specification itself is correct, but the test runs into an error, further test processing for this scenario is aborted, the test steps that ran correctly are displayed as successful and only the incorrect test step is displayed as failed. The remaining test steps of this scenario are then skipped and the test continues with the next scenario.

Existing implementations

best4Automic comes with a set of implementations that are linked to a set in cucumber.conf. These can be used directly in the delivery state without the need for adjustments. Each implementation of a step requires a defined group of parameters so that it can function. These are defined below. A distinction must be made between two types:

Parameters in the record: some parameters are contained directly in the records. These must be defined as named groups in the regular expression.
Parameters in tabular form: These parameters are specified in the lines after a record in the form of a table. A table always has a header line that gives the individual columns a title. The values are defined in the following lines. In all columns except the first, b4A expressions can be used, which are replaced before execution.

given-workflow

Phase: Given
Description: This step checks whether a workflow with a specified list of tasks is available
Parameters
- Set
  - object: Name of the workflow to be checked
- Table
  - Column 1: Task name in the form: <object name>(<consecutive number>)

*Examples

Given Workflow B4A.BASE.JOBP.TEST

Given Workflow B4A.BASE.JOBP.TEST with tasks

    | Task |
    | B4A.BASE.JOBS.TEST(2) |
    | B4A.BASE.JOBS.TEST2(3) |

given-variable-contains

Phase: Given
Description: This step checks whether a variable contains specified keys with the values
Parameters
- Set
  - object: Name of the variable to be checked
- Table: Columns 3 to 6 are optional
  - Column 1: Key of the entry
  - Column 2: Value 1
  - Column 3: Value 2
  - Column 4: Value 3
  - Column 5: Value 4
  - Column 6: Value 5

*Examples

Given variable B4A.BASE.VARA.TEST contains

    | Key | Value 1 | Value 2 |
    | KEY1 | Value 1 | Value 2 |
    | KEY2 | Value 1 | Value 2 |

Given Variable B4A.BASE.VARA.TEST contains in connection AE123-0090

    | Key | Value 1 | Value 2 |
    | KEY1 | Value 1 | Value 2 |
    | KEY2 | Value 1 | Value 2 |

given-object-exists

Phase: Given
Description: This step checks whether an object exists or not. Both variants are possible.
Parameters
- Record
  - object: of the object to be checked
  - negative, positive: Only one of the two can exist. If negative exists, it is checked whether the object does not exist
  - connection: If the parameter is specified, the object is searched for in another connection (optional)

*Examples

Given Object B4A.BASE.STORE.TEST exists

Given Object B4A.BASE.STORE.TEST does not exist

Given Object B4A.BASE.STORE.TEST does not exist in connection AE123-0091

given-folder-exists

Phase: Given
Description: This step checks whether a folder exists in a selected connection or not. Both variants are possible. It is also possible to check whether certain objects are located in this folder.
Parameters
- Set
  - folder: the folder to be checked
  - negative, positive: Only one of the two can exist. If negative exists, it is checked whether the folder does not exist
  - connection: If this parameter is specified, the object is searched for in another connection (optional)
  - objects: If this part of the sentence is specified, the objects in the table are searched for in the folder (optional)
- Table:
  - Column 1: Object name

*Examples

Given Folder B4A/TEST exists

Given Folder B4A/TEST does not exist

Given Folder B4A/TEST exists in connection AE123-0092

Given Folder B4A/TEST exists with objects

    | Object name |
    | B4A.TEST.JOBS.TEST1 |
    | B4A.TEST.JOBS.TEST3 |

given-run-object

Phase: Given
Description: This step executes an object. A logical datum can be set and parameters can be passed via PromptSet
Parameters
- Set
  - object: Name of the object to be executed
  - alias: alias for the execution (optional)
  - date: logical date (optional)
  - success: if the group is not empty, the object must end successfully
  - failure: if the group is not empty, the object must fail
- Table:
  - Column 1: Name of the variable (without leading &)
  - Column 2: Value

*Examples

Given object B4A.TEST.JOBP.TEST ends successfully

Given Object B4A.TEST.JOBP.TEST fails

Given Object B4A.TEST.JOBP.TEST on date 2022-05-31 ends successfully

Given Object B4A.TEST.JOBP.TEST ends successfully

    | Variable | Value |
    | B4AB_FIELD1_I# | TEST1 |
    | B4AB_FIEL21_I# | TEST2 |

given-resolve-agentgroup

Phase: Given
Description: This step can check for the existence of an agent group and resolve it. The resolved agent is made available as a variable for b4A Expressions so that it can be passed on as a parameter. The variable has the same name as the agent group. If the mode of the agent group is set to 'all', then only the first agent is written to the variable.
Parameter
- Record
  - object: Name of the agent group

*Examples

Given Agent group B4A.TEST.HOSTG.TEST exists and can be resolved

given-check-sync

Phase: Given
Description: This step can check the status and value of a sync object for given values
Parameters
- Set
  - object: Name of the sync object
  - state: Expected status of the sync object
  - value: Expected value of the sync object (optional)

*Examples

Given Sync B4A.TEST.SYNC.TEST is in state RUNNING

Given Sync B4A.TEST.SYNC.TEST is in state RUNNING with value 5

given-b4a-options

Phase: Given
Description: In this step, global b4A options can be set for all scenarios of a feature. This step is used in the background of a feature.
Parameters:
- Table:
  - Column 1: Name of the option
  - Column 2: Value

*Examples

Given b4A options



    | Option | Value |
    | log-flags | +MONOCHROME |
    | log-variants | REPORT |
    | log-variants | ERROR,INFO,WARNING,DEBUG |

when-set-variable

Phase: When
Description: This step sets specified values in a static variable. These are added or changed.
Parameters
- Set
  - object: Name of the variable to be checked
- Table: Columns 3 to 6 are optional
  - Column 1: Key of the entry
  - Column 2: Value 1
  - Column 3: Value 2
  - Column 4: Value 3
  - Column 5: Value 4
  - Column 6: Value 5

*Examples

When Set values of variable B4A.TEST.VARA.TEST to

    | Key | Value 1 | Value 2 |
    | KEY1 | Value 1 | Value 2 |
    | KEY2 | Value 1 | Value 2 |

When Set values of variable B4A.TEST.VARA.TEST to

    | Key | Value 1 | Value 2 | Value 3 |
    | KEY1 | Value 1 | Value 2 | Value 3 |
    | KEY2 | Value 1 | Value 2 | Value 5 |

when-reset-variable

Phase: When
Description: This step sets the specified values in a static variable. This is emptied beforehand. If no new values are specified, the variable is only emptied.
Parameters
- Record
  - object: Name of the variable to be checked
- Table: Columns 2 to 6 are optional
  - Column 1: Key of the entry
  - Column 2: Value 1
  - Column 3: Value 2
  - Column 4: Value 3
  - Column 5: Value 4
  - Column 6: Value 5

*Examples

When Reset variable B4A.TEST.VARA.TEST to

    | Key | Value 1 | Value 2 |
    | KEY1 | Value 1 | Value 2 |
    | KEY2 | Value 1 | Value 2 |

When Reset variable B4A.TEST.VARA.TEST

when-save-variable

Phase: When
Description: This step reads object variables of a task from executed workflows. The variable can be saved as an attribute for b4A expressions to be passed as a parameter later.
Parameters
- Set
  - object: Name or alias of the executed object
  - task: Tasks from which the object variable is to be read
  - attribute: Name of the b4A expression attribute
  - variable: Name of the object variable

*Examples

When Execute B4A.TEST.JOBP.TEST(TEST1)

And Remember B4AT_INFO_O# from B4A.TEST.JOBS.TEST of TEST1 as info

And Execute B4A.TEST.JOBP.TEST2

    | Variable | Value |
    | B4AT_INFO_I# | %(info) |

when-remove-variable

Phase: When
Description: This step removes a list of entries from a variable object.
Parameters
- Set
  - object: Name of the variable object
- Table
  - Column 1: Value of the key to be deleted

*Examples

When Remove values from variable B4A.TEST.VARA.TEST

    | Key |
    | KEY1 |
    | KEY2 |

when-execute

Phase: When
Description: This step executes an object. A logical date can be set and parameters can be passed via PromptSet
Parameters
- Set
  - object: Name of the variable to be checked
  - alias: alias for the run (optional)
  - date: logical date (optional)
  - time: Maximum runtime of the object to be executed. When the maximum runtime is reached, the object to be executed is aborted recursively and the test fails. (optional)
- Table
  - Column 1: Name of the variable (without leading &)
  - Column 2: Value (b4A expressions can be used in the value)

*Examples

When Execute B4A.TEST.JOBP.TEST

    | Variable | Value |
    | B4AT_INFO_I# | testing |

When Execute B4A.TEST.JOBP.TEST do not wait longer than 10m

When Execute B4A.TEST.JOBP.TEST on date 2022-05-21

when-create-temp-file

Phase: When
Description: This step can be used to create a temporary text file and optionally define its content. This file is automatically deleted after all tests have been run. The name of the file can be used in other steps of the test via b4A Expressions.
Parameters
- Record
  - attribute: Name of the b4A expression attribute via which the file name can be referenced
- Table
  - Column 1: a line that is written to the temporary file

*Examples

When Create a file remembered as temp_file

    | Line |
    | The first line |
    | A second line |

When Create a temporary file remembered as temp_file

when-cancel-task

Phase: When
Description: This step cancels either a task or a started object. Optionally, the cancelation can also be performed recursively
Parameters
- Record
  - object: Name of the object to be canceled or the parent of the task to be canceled
  - task: Name of the task to be canceled (optional)
  - recursive: If the group is not empty, the abort is performed recursively (optional)

*Examples

When Cancel B4A.TEST.JOBS.TEST1(3) of B4A.TET.JOBP.TEST

When Cancel B4A.TET.JOBP.TEST recursively

when-wait-for-task

Phase: When
Description: This step waits for the end of a task
Parameters
- Set
  - object: Name of the object to which the task belongs
  - task: Name of the task to be waited for
  - time, hours, minutes, seconds: Either the parameter time or a combination of the other three can be used to define the maximum time to wait (optional)

*Examples

When Wait for task B4A.TEST.JOBS.TEST1(3) of B4A.TET.JOBP.TEST for 5m

When Cancel B4A.TET.JOBP.TEST recursively

when-wait

Phase: When
Description: This step waits for a defined time
Parameters
- Set
  - date: date (YYYY-MM-DD) (optional)
  - time: fixed time (HH:MM:SS)
  - hours, minutes, seconds: Specification of hours, minutes and/or seconds to be waited.

*Examples

When Wait until 1h 15m

When Wait until 15:52:00

When Wait until 2022-05-31 15:52:00

when-b4a

Phase: When
Description: This step starts a b4A module with the specified options
Parameters
- Set
  - Module: Name of the module
- Table
  - Column 1: Name of the option
  - Column 2: Value of the option

*Examples

When Start b4A module pm.Install

    | Option | Value |
    | connection | AE123-0090 |
    | zip-file | B4A.BASE |

when-set-sync-state

Phase: When
Description: This step sets the status and value of a sync object. If an action is really to be triggered, we strongly recommend the when-set-sync-action step.
Parameters
- Set
  - object: Sync object whose status and value are to be set.
  - state: Status that is to be set.
  - value: Value by which the current value is to be increased, decreased or set equal to, depending on the operator.
  - operator: Selection of whether the value is to be increased (+), decreased (-) or set equal to (0) by the value specified in value.

*Examples

When Set state of sync B4A.TEST.SYNC.TEST to RUNNING

When Set state of sync B4A.TEST.SYNC.TEST to RUNNING with operator = value 3

when-set-sync-action

Phase: When
Description: This step executes an action on a sync object. If no suitable action can be found for the current status of the sync object, the step fails.
Parameters
- Set
  - object: Sync object on which the action is to be executed.
  - action: Action that is to be executed.

*Examples

When Run action RUNNING on sync B4A.TEST.SYNC.TEST

then-task-status

Phase: Then
Description: This step checks the specified statuses of workflow tasks that were started at when-execute
Parameters
- Set
  - object: Name or alias of the object to which the task belongs. The alias must have previously been used with when-execeute
- Table
  - Column 1: Name of the task
  - Column 2: Status (e.g. ENDED_OK, ANY_OK, ANY_ABEND, ...)

*Examples

    Then Task status of B4A.TEST.JOBP.TEST is

        | Task | Status |
        | B4A.TEST.JOBS.TEST1(2) | ENDED_OK |
        | B4A.TEST.JOBS.TEST2(3) | ANY_OK |

then-task-queue

Phase: Then
Description: This step checks whether tasks of a workflow have used a specified queue during execution
Parameters
- Set
  - object: Name or alias of the object to which the task belongs. The alias must have previously been used with when-execeute
- Table
  - Column 1: Name of the task
  - Column 2: Name of the queue

*Examples

    Then Task queue of B4A.TEST.JOBP.TEST is

        | Task | QUEUE |
        | B4A.TEST.JOBS.TEST1(2) | CLIENT_QUEUE |
        | B4A.TEST.JOBS.TEST2(3) | B4A_QUEUE |

then-task-deactivated

Phase: Then
Description: This step checks whether the specified tasks were deactivated at when-execute
Parameters
- Set
  - object: Name or alias of the object to which the task belongs. The alias must have previously been used with when-execeute
- Table
  - Column 1: Name of the task

*Examples

Then Task of B4A.TEST.JOBP.TEST is deactivated

    | Task |
    | B4A.TEST.JOBS.TEST1(2) |
    | B4A.TEST.JOBS.TEST2(3) |

then-check-object

Phase: Then
Description: This step checks whether an executed object has been successfully completed. The variable CHECK_RUNID#, which contains the RunID from when-execute, is transferred to the object as a PromptSet parameter.
Parameters
- Set
  - object: Name of the object to be executed
  - alias: name or alias of the object that was started with *when-execute
  - success: if the group is not empty, the object must end successfully
  - failure: if the group is not empty, the object must fail

*Examples

Then Check if B4A.TEST.JOBP.CHECK for B4A.TEST.JOBP.TEST ended successfully

Then Check if B4A.TEST.JOBP.CHECK for B4A.TEST.JOBP.TEST has failed

Then Check if B4A.TEST.JOBP.CHECK for B4A.TEST.JOBP.TEST on date 2022-05-28 ended successfully

Then Check if B4A.TEST.JOBP.CHECK for B4A.TEST.JOBP.TEST ended successfully

    | Variable | Value |
    | B4AT_INFO_I# | hello world |

then-task-has-comment

Phase: Then
Description: This step checks whether the specified task has a string in the comments
Parameters
- Set
  - object: Name or alias of the object to which the task belongs. The alias must have previously been used with when-execute
  - task: Name of the task
  - text: Pattern of the text to be searched for in the comments

*examples

Then Comment of task B4A.TEST.JOBS.TEST(2) of B4A.TEST.JOBP.TEST contains .*hello world.*

then-b4a-exitcode

Phase: Then
Description: This step evaluates the exit code of a b4A module
Parameters
- Set
  - Module: Name of the module
  - exitcode: expected exit code of the module

*Examples

Then Exitcode of b4A module pm.Install is 0

then-b4a-report

Phase: Then
Description: This step searches for a regular expression in the report of the b4A module.
Parameters
- Set
  - Module: Name of the module
  - not: if this part of the record exists, the regular expression must not exist in the report
  - pattern: the pattern to be searched for

*Examples

Then Report of b4A module pm.Install contains .*credentials not found.*

Then Report of b4A module pm.Install does not contain .*credentials not found.*

then-compare-variable

Phase: Then
Description: This step compares a variable previously saved with when-save-variable with a regular expression
Parameter
- Set
  - attribute: Name of the b4A expression attribute
  - pattern: regular expression with which the value is to be compared

*Examples

When Execute B4A.TEST.JOBP.TEST(TEST1)

And Remember B4AT_INFO_O# from B4A.TEST.JOBS.TEST of TEST1 as info

Then Compare variable info to .*testing.*

then-check-report

Phase: Then
Description: This step searches for a regular expression in the reports of a task
Parameters
- Set
  - object: Name or alias of the object to which the task belongs. The alias must have previously been used with when-execeute
  - task: Name of the task (optional, if not specified, the report of the above object is searched)
  - reporttype: Type of report to be searched. Valid values: REP, ACT, LOG, PLOG, POST
  - nomatch: if this phrase exists, the regular expression must not exist in the report
  - pattern: regular expression that describes the text fragment to be searched for

*Examples

Then Check report ACT from B4A.TEST.JOBP.TEST for .*a pattern.*

Then Check report REP of B4A.TEST.JOBS.TEST1 from B4A.TEST.JOBP.TEST for .*a pattern.*

Then Check report REP of B4A.TEST.JOBS.TEST1 from B4A.TEST.JOBP.TEST for no match of .*a pattern.*

then-variable-contains

Phase: Then
Description: This step checks whether a specified variable contains the defined keys and values
Parameters
- Set
  - object: Name of the variable to be checked
- Table (columns 3 to 6 are optional)
  - Column 1: Key of the entry
  - Column 2: Value 1
  - Column 3: Value 2
  - Column 4: Value 3
  - Column 5: Value 4
  - Column 6: Value 5

*Examples

Then Check variable B4A.TEST.VARA.TEST contains

    | Key | Value 1 | Value 2 |
    | KEY1 | VALUE1 | VALUE2 |

Then Check variable B4A.TEST.VARA.TEST contains in connection AE123-0094

    | Key | Value 1 | Value 2 |
    | KEY1 | VALUE1 | VALUE2 |

then-object-exists

Phase: Then
Description: This step checks whether an object exists or not. Both variants are possible.
Parameters
- Record
  - object: Name of the object to be checked
  - negative, positive: Only one of the two can exist. If negative exists, it is checked whether the object does not exist
  - connection (optional): If the parameter is specified, the object is searched for in another connection

*Examples

Then Check object B4A.TEST.JOBP.TEST exists

Then Check object B4A.TEST.JOBP.TEST does not exist

Then Check object B4A.TEST.JOBP.TEST exists in connection AE123-0097

then-folder-exists

Phase: Then
Description: This step checks whether a folder exists in a selected connection or not. Both variants are possible. It is also possible to check whether certain objects are located in this folder.
Parameters
- Set
  - Folder: Name of the object to be checked
  - negative, positive: Only one of the two can exist. If negative exists, the regular expression is not included in the check
  - connection: If the parameter is specified, the object is searched for in another connection (optional)

*Examples

Then Check folder B4A/TEST exists

Then Check folder B4A/TEST does not exist

Then Check folder B4A/TEST exists in connection AE123-0093

Then Check folder B4A/TEST exists

    | Object |
    | B4A.TEST.JOBS.TEST1 |
    | B4A.TEST.JOBS.TEST2 |

then-xml-export-contains

Phase: Then
Description: This step checks whether the XML export of an object in a specified connection contains a regular expression (negative as well as positive is possible). The regular expression can refer to several lines in the XML export.
Parameters
- Set
  - object: the folder to be checked
  - negative, positive: Only one of the two can exist. If negative exists, it is checked whether the folder does not exist
  - connection: If the parameter is specified, the object is searched for in another connection (optional)
  - pattern: regular expression that describes the text fragment to be searched for

*Examples

Then Check if XML export of object B4A.TEST.JOBS.TEST contains .*testing.*

Then Check if XML export of object B4A.TEST.JOBS.TEST does not contain .*testing.*

Then Check if XML export of object B4A.TEST.JOBS.TEST in connection AE123-0099 contains .*testing.*

then-set-sync-state

Phase: Then
Description: This step sets the status and value of a sync object. If an action is really to be triggered, we strongly recommend the then-set-sync-action step.
Parameters
- Set
  - object: Sync object whose status and value are to be set.
  - state: Status that is to be set.
  - value: Value by which the current value is to be increased, decreased or set equal to, depending on the operator.
  - operator: Selection of whether the value is to be increased (+), decreased (-) or set equal to (0) by the value specified in value.

*Examples

Then Set state of sync B4A.TEST.SYNC.TEST to RUNNING

Then Set state of sync B4A.TEST.SYNC.TEST to RUNNING with operator = value 3

then-set-sync-action

Phase: Then
Description: This step executes an action on a sync object. If no suitable action can be found for the current status of the sync object, the step fails.
Parameters
- Set
  - object: Sync object on which the action is to be executed.
  - action: Action that is to be executed.

*Examples

Then Run action RUNNING on sync B4A.TEST.SYNC.TEST

then-check-sync

Phase: Then
Description: This step can check the status and value of a sync object for specified values
Parameters
- Set
  - object: Name of the sync object
  - state: Expected status of the sync object
  - value: Expected value of the sync object (optional)

*Examples

Then Sync B4A.TEST.SYNC.TEST is in state RUNNING

Then Sync B4A.TEST.SYNC.TEST is in state RUNNING with value 5

then-workflow

Phase: Then
Description: This step checks whether a workflow with a specified list of tasks is available
Parameters
- Set
  - object: Name of the workflow to be checked
- Table
  - Column 1: Task name in the form: <object name>(<consecutive number>)

*Examples

Then workflow B4A.BASE.JOBP.TEST

Then Workflow B4A.BASE.JOBP.TEST with tasks

    | Task |
    | B4A.BASE.JOBS.TEST(2) |
    | B4A.BASE.JOBS.TEST2(3) |

then-check-messages

Phase: Then
Description: This step searches the messages and checks for the number and a regular expression. It searches for messages that have been reported since the start of the test. Furthermore, only messages from the user himself are considered.
Parameters
- Record
  - negative, positive: Only one of the two can exist. If negative exists, it is checked whether the message does not exist
  - number: Number of the message. This can be specified with the leading letter U or without.
  - pattern: Defines the regular expression that is applied to the message text.

*Examples

Then Check if message exists with number U00011000 and pattern .*test.*

Then Check if message does not exist with number U00011000 and pattern .*test.*

Cucumber​

Predefined regular expressions​

Formats​

b4A Expressions​

Logic during test processing​

Existing implementations​

given-workflow​

given-variable-contains​

given-object-exists​

given-folder-exists​

given-run-object​

given-resolve-agentgroup​

given-check-sync​

given-b4a-options​

when-set-variable​

when-reset-variable​

when-save-variable​

when-remove-variable​

when-execute​

when-create-temp-file​

when-cancel-task​

when-wait-for-task​

when-wait​

when-b4a​

when-set-sync-state​

when-set-sync-action​

then-task-status​

then-task-queue​

then-task-deactivated​

then-check-object​

then-task-has-comment​

then-b4a-exitcode​

then-b4a-report​

then-compare-variable​

then-check-report​

then-variable-contains​

then-object-exists​

then-folder-exists​

then-xml-export-contains​

then-set-sync-state​

then-set-sync-action​

then-check-sync​

then-workflow​

then-check-messages​

Cucumber

Predefined regular expressions

Formats

b4A Expressions

Logic during test processing

Existing implementations

given-workflow

given-variable-contains

given-object-exists

given-folder-exists

given-run-object

given-resolve-agentgroup

given-check-sync

given-b4a-options

when-set-variable

when-reset-variable

when-save-variable

when-remove-variable

when-execute

when-create-temp-file

when-cancel-task

when-wait-for-task

when-wait

when-b4a

when-set-sync-state

when-set-sync-action

then-task-status

then-task-queue

then-task-deactivated

then-check-object

then-task-has-comment

then-b4a-exitcode

then-b4a-report

then-compare-variable

then-check-report

then-variable-contains

then-object-exists

then-folder-exists

then-xml-export-contains

then-set-sync-state

then-set-sync-action

then-check-sync

then-workflow

then-check-messages