Test Automation
Teil eines jeden Entwicklungsprozesses ist die Testphase der entwickelten Funktionalität. Dies Prinzip sollte auch im Bereich der Automation genutzt wurden und ist wie in allen Entwicklungsbereichen ein wichtiger Bestandteil um die Implementierung mit den Anforderungen zu vergleichen und zu bestätigen, dass die gewünschte Stabilität weiterhin gewährleistet ist.
Der Begriff des Testens umfasst ein weiträumiges Gebiet. Dabei gibt es Unterschiede in der Qualität, Quantität und Ausführungstechnik. Die best4Automic Module dieser Kategorie beschäftigen sich mit der Testautomation.
Cucumber
Cucumber ist ein Behavior-Driven-Development-Werkzeug zur textuellen Spezifikation von Anforderungen an Software und zur automatisierten Überprüfung dieser Beschreibung auf ihre korrekte Implementierung. Diese Form der Spezifikation wird im Kontext der Testautomatisierung dafür genutzt Testfälle für Workflows zu definieren und diese automatisiert auszuführen.
Eine Definition (ein sogenanntes Feature) kann aus mehreren Szenarien bestehen. Jedes dieser Szenarien definiert einen Test Case. Alle Szenarien in einem Feature dienen dazu die beschriebene Funktionalität zu testen. Ein Test Case besteht aus drei Phasen:
Given: Überprüfung, ob die Umgebung den Erwartungen entspricht
When: Ausführung der Testschritte
Then: Überprüfung der Ergebnisse der Testausführung
Cucumber ist eine generische Definition, die unabhängig von verschiedenen Testverfahren ist. Für die spezielle Verwendung im Kontext der Automic Automation Engine® wurden Schritte in best4Automic definiert um Testfälle zu spezifizieren. Diese bestehen aus der Festlegung entsprechender Sätze und der umsetzenden Implementierungen, die die Ausführungen bzw. Überprüfungen übernehmen. Für die Zuordnung der Sätze zu den Implementierungen wird ein eindeutiger Schlüssel genutzt. Die Zuordnung ist in der Konfigurationsdatei cucumber.conf definiert. Ausgeliefert wird ein Beispiel, dass für alle existierenden Implementierungen einen entsprechenden Satz definiert. Die Sätze werden als reguläre Ausdrücke definiert, die für jede Implementierung eine genau definierte Menge an Schlüsselwörtern in benannten Gruppen definieren. Beispiel:
when-execute = Execute +@OBJECT_NAME@(:? +on date @DATE@)?(?<parameters> +with parameters)?(?: +do not wait longer than @TIME@)?
Der Schlüssel when-execute definiert einen Schritt, der Objekte in der Automic Automation Engine® aktivieren kann. Dabei kann optional ein logisches Datum übergeben werden und/oder eine Liste von PromptSet-Parametern. Der angegebene reguläre Ausdruck enthält dafür benannten Gruppen object, date und parameters. Die Gruppen object und date sind versteckt in den vordefinierten Variablen @OBJECT_NAME@ und @DATE@.
Beispiele für Cucumber-Definitionen, die diese Sätze nutzen sind im Verzeichnis examples der Distribution zu finden (siehe ta.Execute).
Vordefinierte reguläre Ausdrücke
@OBJECT_NAME@ - regulärer Ausdruck für Objektnamen, der die Gruppe object definiert
@ALIAS@ - regulärer Ausdruck für Aliase, der die Gruppe alias definiert
@OBJECT_VARIABLE@ - regulärer Ausdruck für AE-Script-Variablen, der die Gruppe variable definiert
@TASK_NAME@ - regulärer Ausdruck für Aufgaben, der die Gruppe task definiert
@VARIABLE@ - regulärer Ausdruck für Variablen, die bei einer Test Case-Ausführung zwischengespeichert werden, der die Gruppe attribute definiert
@REPORTTYPE@ - regulärer Ausdruck für Reporttypen, der die Gruppe reporttype definiert
@DATE@ - regulärer Ausdruck, der ein Datum der Form YYYY-MM-DD erkennt und als Gruppe date definiert
@TIME@ - regulärer Ausdruck, der zwei verschiedene Formate von Zeitangaben versteht. Einmal Zeitstempel der Form HH:MM:SS, der als Gruppe „time“ definiert wird. Oder relative Zeitangaben der Form ([0-9]+h)?([0-9]+m)?([0-9]+s)?. Die einzelnen Teile werden als Gruppen hours, minutes und seconds definiert.
@CONNECTION@ - regulärer Ausdruck für eine b4A Verbindung
@FOLDER@ - regulärer Ausdruck für einen Ordner/Pfad in einem Mandant
Formate
Cucumber selbst spezifiziert ein Textformat für die Definitionen, die auf die Syntax von Gherkin aufsetzen. Ein Beispiel sieht wie folgt aus.
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*'
Wenn mehrere Szenarien in einem Feature definiert werden kann es sein, dass die Vorbedingungen der Tests sich ähneln. Anstatt diese bei jedem Szenario zu wiederholen können die gemeinsamen Vorbedingungen auch in einer Background Definition innerhalb des Feature ausgelagert werden.
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.]+!"
Zusätzlich ist es möglich Szenarien und Features mit Tags zu markieren. Jedes Tag muss mit einem @ anfangen. Werden mehrere Tags angeben so sind diese durch Leerzeichen voneinander zu trennen. Werden die Tests mit dem b4A Modul ta.Execute gestartet ist es möglich eine Liste von Tags zu übergeben. In diesem Fall werden nur Tests ausgeführt, die mindestens eins der angegebenen Tags besitzen. Eine weitere Option ermöglicht es eine Liste von Tags anzugeben, die zum Ausschluss von Tests führt. Auch dabei reicht es wenn ein Test eines der angegebenen Tags besitzt. Bei der Ausführung wird zuerst die Liste der Tags geprüft, die Tests zulassen und anschließend die Liste der Tags, die zum Ausschluss führen.
Alle b4A Module, die sich mit Cucumber beschäftigen, können Cucumber-Definitionen in eine strukturierte Dokumentation an einem Objekt überführen und dort gegebenenfalls auch die Testergebnisse protokollieren. Diese Struktur wird im folgenden erläutert.
b4A Expressions
In den Testspezifikationen können b4A Expressions genutzt werden, um die
Definitionen flexibel zu halten. Beispielsweise können Zeitpunkte oder
Datumsangaben als b4A Expression angegeben werden, damit diese nicht zu einem
einzigen Zeitpunkt stimmen, sondern sich dynamisch anpassen. Dafür können die
die Funktionen %{DATE::} und %{TIME::} genutzt werden. Des Weiteren stehen folgende Attribute zur Verfügung:
b4A
connection: Name der b4A Verbindungen
client: Nummer des genutzten Mandant
system: Name des Automic Automation Engine® Systems
username: Benutzername der aktuellen Verbindung
department: Abteilung des aktuellen Benutzers
timezone: Zeitzone der aktuellen Verbindung
language: Sprache der aktuellen Verbindung
version: Versionsnummer der Automic Automation Engine®
Beispiel:
Verbindung: %(b4A.connection)
System: %(b4A.system)
Mandant: %(b4A.client))
Logik bei der Testverarbeitung
Bei der Ausführung der Testfälle wird zuerst die gesamte Testspezifikation eingelesen. Dabei werden die b4A Expressions zur Laufzeit ersetzt. Jeder Testschritt in der Testspezifikation wird dabei auf eine der bestehenden Implementierungen abgebildet. Wird zu einem Testschritt, also einem Satz, keine bestehende Implementierung gefunden, handelt es sich um eine fehlerhafte Testspezifikation. Das Einlesen wird dabei aber nicht abgebrochen. Es gibt lediglich einen Hinweis im Report. Danach werden die Szenarien nacheinander Schritt für Schritt abgearbeitet. Enthält ein Szenario dabei eine fehlerhafte Testspezifikation, so wird die Verarbeitung des Szenarios übersprungen. Die Fortschrittsanzeige zeigt bei einem solchen Szenario die Anzahl der erfolgreich eingelesenen Testschritte plus dem fehlerhaften als gescheitert an. Ist die Testspezifikation selbst korrekt, der Test läuft aber auf einen Fehler, dann wird die weitere Testverarbeitung für dieses Szenario abgebrochen, die korrekt gelaufenen Testschritte als erfolgreich angezeigt und nur der fehlerhafte als gescheitert. Die restlichen Testschritte dieses Szenarios werden dann übersprungen und mit dem nächsten Szenario fortgefahren.
Vorhandene Implementierungen
best4Automic bringt einen Satz von Implementierung mit, die entsprechend in der cucumber.conf mit einem Satz verknüpft sind. Diese können direkt im Auslieferungszustand genutzt werden ohne das Anpassungen notwendig sind. Jede Implementierung eines Schritts benötigt eine definierte Gruppe von Parametern, damit diese funktionieren kann. Diese werden im folgenden definiert. Dabei ist zwischen zwei Arten zu unterscheiden:
Parameter im Satz: einige Parameter sind direkt in den Sätzen enthalten. Diese müssen im regulären Ausdruck als benannte Gruppen definiert werden.
Parameter in tabellarischer Form: Diese Parameter werden in den Zeilen nach einem Satz in Form einer Tabelle angegeben. Dabei hat eine Tabelle immer eine Kopfzeile, die den einzelnen Spalten einen Titel gibt. In den folgenden Zeilen werden die Werte definiert. In allen Spalten außer der ersten können b4A Expressions genutzt, welche vor der Ausführung ersetzt werden.
given-workflow
Phase: Given
Beschreibung: Dieser Schritt Überprüft ob ein Workflow mit einer angegebenen Liste von Aufgaben verfügbar ist
Parameter
Satz
object: Name des zu prüfenden Workflows
Tabelle
Spalte 1: Aufgabenname in der Form: <Objektname>(<laufende Nummer>)
Beispiele
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
Beschreibung: Dieser Schritt überprüft, ob eine Variable angegebene Keys mit den Werten enthält
Parameter
Satz
object: Name der zu prüfenden Variable
Tabelle: Die Spalten 3 bis 6 sind optional
Spalte 1: Key des Eintrags
Spalte 2: Wert 1
Spalte 3: Wert 2
Spalte 4: Wert 3
Spalte 5: Wert 4
Spalte 6: Wert 5
Beispiele
Given Variable B4A.BASE.VARA.TEST contains
| Key | Value 1 | Value 2 |
| KEY1 | Wert 1 | Wert 2 |
| KEY2 | Wert 1 | Wert 2 |
Given Variable B4A.BASE.VARA.TEST contains in connection AE123-0090
| Key | Value 1 | Value 2 |
| KEY1 | Wert 1 | Wert 2 |
| KEY2 | Wert 1 | Wert 2 |
given-object-exists
Phase: Given
Beschreibung: Dieser Schritt Überprüft, ob ein Objekt existiert oder auch nicht. Beide Varianten sind möglich.
Parameter
Satz
object: des zu prüfenden Objektes
negative, positive: Nur einer der beide kann existieren. Existiert negative wird geprüft, ob das Objekt nicht existiert
connection: Wird der Parameter angegeben, dann wird das Objekt in einer anderen Verbindung gesucht (optional)
Beispiele
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
Beschreibung: Dieser Schritt überprüft, ob ein Ordner in einer ausgewählten Verbindung existiert oder auch nicht. Beide Varianten sind möglich. Zudem kann geprüft werden, ob sich bestimmte Objekte in diesem Ordner befinden.
Parameter
Satz
folder: der zu prüfende Ordner
negative, positive: Nur einer der beiden kann existieren. Existiert negative wird geprüft, ob der Ordner nicht existiert
connection: Wird der Parameter angegeben, dann wird das Objekt in einer anderen Verbindung gesucht (optional)
objects: wird dieser Satzteil angegeben, dann werden die Objekte in der Tabelle in dem Ordner gesucht (optional)
Tabelle:
Spalte 1: Objektname
Beispiele
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
Beschreibung: Dieser Schritt führt ein Objekt aus. Dabei kann ein logisches Datum gesetzt und Parameter per PromptSet übergeben werden
Parameter
Satz
object: Name des auszuführenden Objektes
alias: Alias für die Ausführung (optional)
date: logisches Datum (optional)
success: ist die Gruppe nicht leer, dann muss das Objekt erfolgreich enden
failure: ist die Gruppe nicht leer, dann muss das Objekt fehlschlagen
Tabelle:
Spalte 1: Name der Variable (ohne führendes &)
Spalte 2: Wert
Beispiele
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
Beschreibung: Dieser Schritt kann auf die Existenz einer Agentengruppe prüfen und diese auflösen. Der aufgelöste Agent wird als Variable für b4A Expressions zur Verfügung stellt, so dass diese als Parameter weiter gegeben werden kann. Die Variable heißt genauso wie die Agentengruppe. Wenn der Modus der Agentengruppe ‚alle‘ gesetzt ist, dann wird nur der erste Agent in die Variable geschrieben.
Parameter
Satz
object: Name der Agentengruppe
Beispiele
Given Agent group B4A.TEST.HOSTG.TEST exists and can be resolved
given-check-sync
Phase: Given
Beschreibung: Dieser Schritt kann den Status und den Wert eines Sync Objekts auf mitgegebene Werte prüfen
Parameter
Satz
object: Name des Sync-Objekts
state: Erwarteter Status des Sync-Objekts
value: Erwarteter Wert des Sync-Objekts (optional)
Beispiele
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
Beschreibung: In diesem Schritt können globale b4A Optionen für alle Szenarien eines Features gesetzt werden. Dieser Schritt wird im Background eines Features verwendet.
Parameter:
Tabelle:
Spalte 1: Name der Option
Spalte 2: Wert
Beispiele
Given b4A options
| Option | Value |
| log-flags | +MONOCHROME |
| log-variants | REPORT |
| log-variants | ERROR,INFO,WARNING,DEBUG |
when-set-variable
Phase: When
Beschreibung: Dieser Schritt setzt angegebene Werte in einer statischen Variable. Diese werden hinzugefügt oder geändert.
Parameter
Satz
object: Name der zu prüfenden Variable
Tabelle: Die Spalten 3 bis 6 sind optional
Spalte 1: Key des Eintrags
Spalte 2: Wert 1
Spalte 3: Wert 2
Spalte 4: Wert 3
Spalte 5: Wert 4
Spalte 6: Wert 5
Beispiele
When Set values of variable B4A.TEST.VARA.TEST to
| Key | Value 1 | Value 2 |
| KEY1 | Wert 1 | Wert 2 |
| KEY2 | Wert 1 | Wert 2 |
When Set values of variable B4A.TEST.VARA.TEST to
| Key | Value 1 | Value 2 | Value 3 |
| KEY1 | Wert 1 | Wert 2 | Wert 3 |
| KEY2 | Wert 1 | Wert 2 | Wert 5 |
when-reset-variable
Phase: When
Beschreibung: Dieser Schritt setzt angegebene Werte in einer statischen Variable. Diese wird zuvor geleert. Werden keine neuen Werte angegeben, dann wird die Variable ausschließlich geleert.
Parameter
Satz
object: Name der zu prüfenden Variable
Tabelle: Die Spalten 2 bis 6 sind optional
Spalte 1: Key des Eintrags
Spalte 2: Wert 1
Spalte 3: Wert 2
Spalte 4: Wert 3
Spalte 5: Wert 4
Spalte 6: Wert 5
Beispiele
When Reset variable B4A.TEST.VARA.TEST to
| Key | Value 1 | Value 2 |
| KEY1 | Wert 1 | Wert 2 |
| KEY2 | Wert 1 | Wert 2 |
When Reset variable B4A.TEST.VARA.TEST
when-save-variable
Phase: When
Beschreibung: Dieser Schritt liest Objekt-Variablen einer Aufgaben von ausgeführten Workflows aus. Die Variable kann als Attribute für b4A Expressions gespeichert werden um später als Parameter übergeben zu werden.
Parameter
Satz
object: Name oder Alias des ausgeführten Objektes
task: Aufgaben von der die Objekt-Variable gelesen werden soll
attribute: Name des b4A Expression-Attributs
variable: Name der Objekt-Variable
Beispiele
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
Beschreibung: Dieser Schritt entfernt eine Liste von Einträgen aus einem Variable-Objekt.
Parameter
Satz
object: Name des Variable-Objektes
Tabelle
Spalte 1: Wert des zu löschenden Keys
Beispiele
When Remove values from variable B4A.TEST.VARA.TEST
| Key |
| KEY1 |
| KEY2 |
when-execute
Phase: When
Beschreibung: Dieser Schritt führt ein Objekt aus. Dabei kann ein logisches Datum gesetzt und Parameter per PromptSet übergeben werden
Parameter
Satz
object: Name der zu prüfenden Variable
alias: Alias für den Lauf (optional)
date: logisches Datum (optional)
time: Maximale Laufzeit des auszuführenden Objekts. Bei Erreichen der maximalen Laufzeit wird das auszuführende Objekt rekursiv abgebrochen und der Test schlägt fehl. (optional)
Tabelle
Spalte 1: Name der Variable (ohne führendes &)
Spalte 2: Wert (in dem Wert können b4A Expressions genutzt werden)
Beispiele
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
Beschreibung: Mit diesem Schritt kann eine temporäre Textdatei erzeugt und optional deren Inhalt definiert werden. Nach dem Durchlauf aller Tests wird diese Datei automatisch gelöscht. Der Name der Datei kann über b4A Expressions in anderen Schritten des Tests genutzt werden.
Parameter
Satz
attribute: Name des b4A Expression Attributs über den der Dateiname referenziert werden kann
Tabelle
Spalte 1: eine Zeile, die in die temporäre Datei geschrieben wird
Beispiele
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
Beschreibung: Dieser Schritt bricht entweder eine Aufgabe oder ein gestartetes Objekt ab. Optional kann der Abbruch auch rekursiv durchgeführt werden
Parameter
Satz
object: Name des abzubrechenden Objektes oder der Parent der abzubrechenden Aufgabe
task: Name der abzubrechenden Aufgabe (optional)
recursive: Ist die Gruppe nicht leer, dann wird der Abbruch rekursiv duchgeführt (optional)
Beispiele
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
Beschreibung: Dieser Schritt wartet auf das Ende einer Aufgabe
Parameter
Satz
object: Name des Objektes zum die Aufgabe gehört
task: Name der Aufgabe auf die gewartet werden soll
time, hours, minutes, seconds: Entweder mit dem Parameter time oder einer Kombination aus den anderen drei kann definiert werden wie lange maximal gewartet werden soll (optional)
Beispiele
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
Beschreibung: Dieser Schritt wartet auf einen definierten Zeitpunkt
Parameter
Satz
date: Datum (YYYY-MM-DD) (optional)
time: fest definierter Zeitpunkt (HH:MM:SS)
hours, minutes, seconds: Angabe von Stunden, Minuten und/oder Sekunden, die gewartet werden soll.
Beispiele
When Wait until 1h 15m
When Wait until 15:52:00
When Wait until 2022-05-31 15:52:00
when-b4a
Phase: When
Beschreibung: Dieser Schritt startet ein b4A Modul mit den angegebenen Optionen
Parameter
Satz
module: Name des Moduls
Tabelle
Spalte 1: Name der Option
Spalte 2: Wert der Option
Beispiele
When Start b4A module pm.Install
| Option | Value |
| connection | AE123-0090 |
| zip-file | B4A.BASE |
when-set-sync-state
Phase: When
Beschreibung: Dieser Schritt setzt den Status und den Wert eines Sync Objekts. Soll wirklich eine Action getriggert werden, so empfehlen wir dringend den Schritt when-set-sync-action.
Parameter
Satz
object: Sync Objekt, dessen Status und Wert gesetzt werden soll.
state: Status, der gesetzt werden soll.
value: Wert, um den der aktuelle Wert je nach Operator erhöht, verringert oder gleich gesetzt werden soll.
operator: Auswahl, ob der Wert um den in value angegebenen Wert erhöht (+), verringert (-) oder gleichgesetzt (0) werden soll.
Beispiele
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
Beschreibung: Dieser Schritt führt eine Action auf ein Sync Objekt aus. Lässt sich keine passende Action für den aktuellen Status des Sync Objekts finden, schlägt der Schritt fehl.
Parameter
Satz
object: Sync Objekt, auf das die Action ausgeführt werden soll.
action: Action, die ausgeführt werden soll.
Beispiele
When Run action RUNNING on sync B4A.TEST.SYNC.TEST
then-task-status
Phase: Then
Beschreibung: Dieser Schritt prüft die angegebenen Status von Workflow-Aufgaben, die bei when-execute gestartet worden sind
Parameter
Satz
object: Name oder Alias des Objektes zu dem die Aufgabe gehört. Der Alias muss zuvor mit when-execeute genutzt worden sein
Tabelle
Spalte 1: Name der Aufgabe
Spalte 2: Status (z.B. ENDED_OK, ANY_OK, ANY_ABEND, …)
Beispiele
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
Beschreibung: Dieser Schritt prüft ob Aufgaben eines Workflow eine angegebene Queue bei der Ausführung genutzt haben
Parameter
Satz
object: Name oder Alias des Objektes zu dem die Aufgabe gehört. Der Alias muss zuvor mit when-execeute genutzt worden sein
Tabelle
Spalte 1: Name der Aufgabe
Spalte 2: Name der Queue
Beispiele
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
Beschreibung: Dieser Schritt prüft, ob die angegebenen Aufgaben bei when-execute deaktiviert waren
Parameter
Satz
object: Name oder Alias des Objektes zu dem die Aufgabe gehört. Der Alias muss zuvor mit when-execeute genutzt worden sein
Tabelle
Spalte 1: Name der Aufgabe
Beispiele
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
Beschreibung: Dieser Schritt prüft ob ein ausgeführtes Objekt erfolgreich beendet wurde. Als PromptSet-Parameter wird dem Objekt die Variable CHECK_RUNID# übergeben, die die RunID aus when-execute enthält.
Parameter
Satz
object: Name des auszuführenden Objektes
alias: Name oder Alias des Objektes, dass mit when-execute gestartet wurde
success: ist die Gruppe nicht leer, dann muss das Objekt erfolgreich enden
failure: ist die Gruppe nicht leer, dann muss das Objekt fehlschlagen
Beispiele
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
Beschreibung: Dieser Schritt prüft ob die angegebene Aufgabe eine Zeichenkette in den Kommentaren hat
Parameter
Satz
object: Name oder Alias des Objektes zu dem die Aufgabe gehört. Der Alias muss zuvor mit when-execute genutzt worden sein
task: Name der Aufgabe
text: Muster des zu suchenden Textes in den Kommentaren
Beispiele
Then Comment of task B4A.TEST.JOBS.TEST(2) of B4A.TEST.JOBP.TEST contains .*hello world.*
then-b4a-exitcode
Phase: Then
Beschreibung: Dieser Schritt wertet den Exit-Code eines b4A Moduls aus
Parameter
Satz
module: Name des Moduls
exitcode: erwarteter Exit-Code des Moduls
Beispiele
Then Exitcode of b4A module pm.Install is 0
then-b4a-report
Phase: Then
Beschreibung: Dieser Schritt sucht in dem Bericht des b4A Moduls nach einem regulären Ausdruck
Parameter
Satz
module: Name des Moduls
not: existiert dieser Satzteil, dann darf der reguläre Ausdruck im Bericht nicht existieren
pattern: das zu suchende Muster
Beispiele
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
Beschreibung: Dieser Schritt vergleicht eine zuvor mit when-save-variable gespeicherte Variable mit einem regulären Ausdruck
Parameter
Satz
attribute: Name des b4A-Expression-Attributs
pattern: regulärer Ausdruck mit dem der Wert verglichen werden soll
Beispiele
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
Beschreibung: Dieser Schritt sucht nach einem regulären Ausdruck in den Reports einer Aufgabe
Parameter
Satz
object: Name oder Alias des Objektes zu dem die Aufgabe gehört. Der Alias muss zuvor mit when-execeute genutzt worden sein
task: Name der Aufgabe (optional, wenn nicht angegeben, wird der Report des obigen Objekts durchsucht)
reporttype: Typ des Reports, der durchsucht werden soll. Gültige Werte: REP, ACT, LOG, PLOG, POST
nomatch: existiert diese Frase, dann darf der reguläre Ausdruck im Bericht nicht existieren
pattern: regulärer Ausdruck, der das zu suchende Textfragment beschreibt
Beispiele
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
Beschreibung: Dieser Schritt prüft, ob eine angegebene Variable die definierten Keys und Werte enthält
Parameter
Satz
object: Name der zu prüfenden Variable
Tabelle (die Spalten 3 bis 6 sind optional)
Spalte 1: Key des Eintrags
Spalte 2: Wert 1
Spalte 3: Wert 2
Spalte 4: Wert 3
Spalte 5: Wert 4
Spalte 6: Wert 5
Beispiele
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
Beschreibung: Dieser Schritt Überprüft, ob ein Objekt existiert oder auch nicht. Beide Varianten sind möglich.
Parameter
Satz
object: Name des zu prüfenden Objektes
negative, positive: Nur einer der beide kann existieren. Existiert negative wird geprüft, ob das Objekt nicht existiert
connection (optional): Wird der Parameter angegeben, dann wird das Objekt in einer anderen Verbindung gesucht
Beispiele
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
Beschreibung: Dieser Schritt überprüft, ob ein Ordner in einer ausgewählten Verbindung existiert oder auch nicht. Beide Varianten sind möglich. Zudem kann geprüft werden, ob sich bestimmte Objekte in diesem Ordner befinden.
Parameter
Satz
folder: Name des zu prüfenden Objektes
negative, positive: Nur einer der beiden kann existieren. Existiert negative wird geprüft, der reguläre Ausdruck nicht enthalten ist
connection: Wird der Parameter angegeben, dann wird das Objekt in einer anderen Verbindung gesucht (optional)
Beispiele
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
Beschreibung: Dieser Schritt überprüft, ob der XML-Export eines Objektes in einer angegebenen Verbindung einen regulären Ausdruck enthält (negativ sowie positiv ist möglich). Der reguläre Ausdruck kann sich auf mehrere Zeile in dem XML-Export beziehen.
Parameter
Satz
object: der zu prüfende Ordner
negative, positive: Nur einer der beiden kann existieren. Existiert negative wird geprüft, ob der Ordner nicht existiert
connection: Wird der Parameter angegeben, dann wird das Objekt in einer anderen Verbindung gesucht (optional)
pattern: regulärer Ausdruck, der das zu suchende Textfragment beschreibt
Beispiele
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
Beschreibung: Dieser Schritt setzt den Status und den Wert eines Sync Objekts. Soll wirklich eine Action getriggert werden, so empfehlen wir dringend den Schritt then-set-sync-action.
Parameter
Satz
object: Sync Objekt, dessen Status und Wert gesetzt werden soll.
state: Status, der gesetzt werden soll.
value: Wert, um den der aktuelle Wert je nach Operator erhöht, verringert oder gleich gesetzt werden soll.
operator: Auswahl, ob der Wert um den in value angegebenen Wert erhöht (+), verringert (-) oder gleichgesetzt (0) werden soll.
Beispiele
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
Beschreibung: Dieser Schritt führt eine Action auf ein Sync Objekt aus. Lässt sich keine passende Action für den aktuellen Status des Sync Objekts finden, schlägt der Schritt fehl.
Parameter
Satz
object: Sync Objekt, auf das die Action ausgeführt werden soll.
action: Action, die ausgeführt werden soll.
Beispiele
Then Run action RUNNING on sync B4A.TEST.SYNC.TEST
then-check-sync
Phase: Then
Beschreibung: Dieser Schritt kann den Status und den Wert eines Sync Objekts auf mitgegebene Werte prüfen
Parameter
Satz
object: Name des Sync-Objekts
state: Erwarteter Status des Sync-Objekts
value: Erwarteter Wert des Sync-Objekts (optional)
Beispiele
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
Beschreibung: Dieser Schritt Überprüft ob ein Workflow mit einer angegebenen Liste von Aufgaben verfügbar ist
Parameter
Satz
object: Name des zu prüfenden Workflows
Tabelle
Spalte 1: Aufgabenname in der Form: <Objektname>(<laufende Nummer>)
Beispiele
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
Beschreibung: Dieser Schritt durchsucht die Meldungen und prüft dabei auf die Nummer sowie auf einen regulären Ausdruck. Gesucht wird in Nachrichten, die seit dem Start des Tests gemeldet wurden. Des Weiteren werden nur Nachrichten des Benutzers selbst betrachtet.
Parameter
Satz
negative, positive: Nur einer der beiden kann existieren. Existiert negative wird geprüft, ob die Meldung nicht existiert
number: Nummer der Meldung. Diese kann mit dem führenden Buchstaben U oder ohne angegeben werden.
pattern: Definiert den regulären Ausdruck, der auf den Meldungstext angewendet wird.
Beispiele
Then Check if message exists with number U00011000 and pattern .*test.*
Then Check if message does not exist with number U00011000 and pattern .*test.*