Test Automation ¶

Inhalt

Test Automation
- Cucumber
- Module

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.

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>)

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

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)

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)
- Tabelle:
  Spalte 1: Objektname

given-run-object

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 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

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

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)

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

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

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

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

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

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)

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

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)

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 Aufgabeauf 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)

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.

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

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.

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.

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, …)

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

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

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

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-execeute genutzt worden sein
  
  task: Name der Aufgabe
  
  text: Muster des zu suchenden Textes in den Kommentaren

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

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 diese Frase, dann darf der reguläre Ausdruck im Bericht nicht existieren
  
  pattern: das zu suchende Muster

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

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

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

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

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)

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)
- Tabelle:
  Spalte 1: Objektname

then-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 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.

then-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.

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)

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>)

Test Automation¶

Cucumber¶