Robot Framework Tutorial mit Playwright: Datengetriebene Tests, Docker und CI

Robot Framework eignet sich für Teams, die automatisierte Tests lesbar formulieren und technische Browserdetails trotzdem sauber kapseln wollen. Das Framework verwendet eine tabellarische, schlüsselwortgetriebene (keyword-driven) Syntax. Ein Testfall liest sich dadurch eher wie eine fachliche Beschreibung als wie ein klassisches Automatisierungsskript.

Dieser Artikel hat zwei Schwerpunkte. Er zeigt erstens, wie Robot Framework, die Playwright-basierte Browser-Library, Docker und CI zu einem vollständigen E2-UI-Testablauf zusammenspielen. Zweitens vergleicht er drei Ansätze für datengetriebene Tests: DataDriver mit CSV, einen eigenen Python-Reader für CSV und RPA Framework für Excel-Arbeitsmappen. Die Testlogik bleibt dabei gleich, während sich Datenquelle, Validierung, Testisolation und Darstellung im Report unterscheiden.

Das Demo-Projekt führt vom ersten vollständigen Testlauf bis zur Struktur einzelner Suites, Keywords und Datenquellen. Der Schwerpunkt liegt auf einer wartbaren Struktur, die sich auf größere Test-Suites übertragen lässt.

Was ist Robot Framework?

Robot Framework ist ein in Python implementiertes, schlüsselwortgetriebenes Automatisierungsframework. Es wird vor allem für Akzeptanztests, Acceptance Test-Driven Development und Regressionstests eingesetzt. Der Kern des Frameworks kennt die zu testende Anwendung nicht. Er liest Testdaten, führt Keywords aus und erzeugt Logs sowie Reports. Die Verbindung zum Browser, zu einer API, einer Datenbank oder einem Betriebssystem erfolgt über Bibliotheken.

Diese Trennung ist zentral:

• Robot Framework steuert Ausführung, Variablen, Kontrollstrukturen und Reporting.
• Bibliotheken stellen technische Keywords bereit.
• Resource-Dateien kombinieren technische Keywords zu fachlichen Aktionen.
• Test-Suites beschreiben das erwartete Verhalten.

Im Projekt übernimmt die Browser-Library, die auf Playwright basiert, die Webautomatisierung. Zu den grundlegenden Robot-Konzepten gehören: Libraries importieren, Keywords aufrufen, Zustände prüfen und wiederverwendbare Abläufe in Resource-Dateien auslagern.

Robot Framework reduziert nicht den Bedarf an technischem Verständnis. Selektoren, asynchrone Browserzustände, Testdaten, Isolation und CI bleiben anspruchsvoll. Das Framework verschiebt diese Details aber aus den fachlichen Testfällen in klar abgegrenzte technische Schichten. Der Vorteil ist, dass sich Robot-Tests leichter mit dem Fachbereich besprechen lassen.

Wie diese Trennung in einem vollständigen Testprojekt umgesetzt wird, zeigt das folgende Demo-Projekt.

Ziel und Umfang des Demo-Projekts

Das Repository testet ausschließlich die Weboberfläche des OWASP Juice Shop. Dieser Webshop ist OpenSource und eignet sich als Testobjekt (SUT), weil er eine realistische Single-Page-Anwendung mit Suche, Warenkorb und Login bereitstellt. Der Shop läuft lokal in einem Docker-Container. Robot Framework läuft direkt auf dem Entwicklungsrechner oder auf einem CI-Runner und greift über http://127.0.0.1:3000 auf die Anwendung zu. Neben den fachlichen UI-Journeys demonstriert das Projekt mehrere Data-Driven-Ansätze für denselben Suchtest. Dadurch lassen sich nicht nur die Datenformate, sondern auch ihre Auswirkungen auf Reports, Isolation und Wartung vergleichen.

Das Demo-Projekt deckt folgende UI-Testfälle ab:

• Die Startseite lädt und zeigt Produktkarten.
• Eine Suche filtert den Katalog korrekt.
• Produktdetails lassen sich öffnen und schließen.
• Ein anonymer Warenkorb startet leer und zeigt hinzugefügte Mengen korrekt.
• Ein angemeldeter Benutzer kann eine Menge erhöhen, worauf sich der Gesamtpreis korrekt ändert.
• Ein neues Konto kann registriert werden.
• Gültige und ungültige Login-Versuche werden geprüft.

Um diesen Testumfang lokal und in der Pipeline reproduzierbar abzubilden, kombiniert das Projekt mehrere klar abgegrenzte Werkzeuge.

Die verwendeten Werkzeuge

Das Projekt kombiniert folgende Werkzeuge mit getrennten Aufgaben:

• Python stellt die Laufzeit bereit und wird für kleine Hilfsskripte verwendet.
• Robot Framework führt Test-Suiten aus und erzeugt Ergebnisse.
• Robot Framework Browser steuert Chromium über Playwright.
• Robot Framework DataDriver erzeugt Tests aus CSV-Zeilen.
• RPA Framework liest Excel-Arbeitsmappen mit RPA.Excel.Files
• Docker Compose startet OWASP Juice Shop lokal und in der CI-Pipeline.
• GitHub Actions führt denselben Ablauf für Pull Requests und Änderungen auf main aus.
• GitHub Pages veröffentlicht die neuesten Testergebnisse.
• Robocop analysiert und formatiert Robot-Dateien nach offiziellen Robot Framework Style Guide.

Mit diesen Bausteinen kann das Projekt zunächst vollständig gestartet werden, bevor die einzelnen Dateien und Konzepte im Detail betrachtet werden.

Installation des Projekts

Der Quellcode des Demo-Projekts liegt unter: GitHub – RobotFramework Python JuiceShop Tutorial

Für den lokalen Lauf werden Python 3.11 oder neuer, Git, Node.js sowie Docker mit Docker-Compose-Unterstützung benötigt. Die folgenden Befehle werden aus einem Terminal ausgeführt. Nach dem Klonen müssen alle weiteren Befehle im Root-Verzeichnis des Repositorys laufen.

git clone https://github.com/teqs-academy/RobotFramework_Python_JuiceShop_Tutorial
cd RobotFramework_Python_JuiceShop_Tutorial
python -m pip install -e .
rfbrowser init

python -m pip install -e . installiert die im Projekt definierten Python-Abhängigkeiten. rfbrowser init richtet die Node- und Playwright-Abhängigkeiten der Browser-Library ein.

Für Entwicklung, statische Analyse und Formatierungsprüfungen kann die optionale Abhängigkeitsgruppe installiert werden:

python -m pip install -e ".[dev]"
python -m robocop check tests
python -m robocop format --check tests

robocop check meldet mögliche Fehler und Qualitätsprobleme. robocop format --check prüft, ob eine Formatierung nötig wäre, ohne Dateien zu verändern. Die im Projekt unterstützten Versionsbereiche stehen in pyproject.toml; diese Datei ist die maßgebliche Referenz für die Abhängigkeiten.

Docker Compose startet die im Projekt definierte Version von OWASP Juice Shop:

docker compose -f webshop_app/docker-compose.yml up -d

Der Webshop ist unter http://127.0.0.1:3000 erreichbar.

Den ersten Testlauf ausführen

Nachdem der Webshop läuft, kann der erste Test gestartet werden. Es empfiehlt sich, zunächst einen kleinen, schnell verständlichen Test auszuführen, bevor die gesamte Suite läuft.

Der kleinste vollständige Test im Projekt ist `Homepage Smoke`. Er prüft, ob die Startseite geladen wird und Produktkarten anzeigt:

*** Settings ***
Resource            ../resources/juice_shop.resource

Test Setup          Open Shop Homepage
Test Teardown       Handle Test Cleanup

*** Test Cases ***
Homepage Smoke
    [Documentation]    Verify that the webshop homepage loads and shows the catalog.
    Catalog Should Show Products

Dieser einzelne Test lässt sich mit `–test` aus der Suite `shop_journeys.robot` auswählen und ausführen. Robot Framework legt den Ergebnisordner bei Bedarf an und schreibt dort die Reports ab:

python -m robot --outputdir results --test "Homepage Smoke" tests/robot/shop_journeys.robot

Wenn der Smoke-Test erfolgreich ist, kann die gesamte Testsuite gestartet werden:

python -m robot --outputdir results tests/robot

Auch einzelne Suites lassen sich gezielt ausführen. Das ist beim Entwickeln oder bei der Fehlersuche nützlich, weil nur der betreffende Bereich läuft:

python -m robot --outputdir results tests/robot/basket.robot

Nach jedem Lauf liegen `report.html`, `log.html` und `output.xml` im Ordner `results/`. Bei einem Fehler speichert das Teardown außerdem Screenshots in diesem Ordner. Der nächste Abschnitt zeigt, wie diese Dateien für die Diagnose verwendet werden.

Reports und Logs lesen

Robot Framework erzeugt standardmäßig drei zentrale Dateien:

• report.html zeigt den Gesamtstatus, Statistiken und Suite-Ergebnisse.
• log.html enthält den detaillierten Ausführungsbaum mit Keywords, Argumenten, Zeitstempeln und Fehlermeldungen.
• output.xml ist das maschinenlesbare Ergebnis für Nachbearbeitung und Integrationen. Diese Datei kann optional mit rebot weiterverarbeitet werden.

Der Report beantwortet die Frage, ob etwas fehlgeschlagen ist. Das Log erklärt meist, warum es fehlgeschlagen ist. Es lohnt sich, log.html auch nach einem erfolgreichen ersten Lauf zu öffnen. Zu tief verschachtelte Keywords, unnötig geloggte Daten und schwer lesbare Abläufe werden dort früher sichtbar als im Quelltext.

Bei UI-Fehlern kommen Screenshots aus dem Teardown hinzu. Das Projekt speichert sie unterhalb des Ergebnisverzeichnisses. Screenshot, Keyword-Log und Zeitpunkt des Fehlers ergeben gemeinsam ein deutlich besseres Diagnosebild als eine einzelne Assertion-Meldung.

So sieht report.html nach einem abgeschlossenen Lauf aus, mit Gesamtstatus und Statistiken pro Suite:

Lokale Umgebung beenden

Der lokale `OWASP Juice Shop` Container bleibt nach dem Testlauf aktiv. So können weitere Tests ausgeführt werden, ohne den Shop erneut zu starten. Wenn keine weiteren lokalen Läufe geplant sind, kann die Umgebung beendet werden:

docker compose -f webshop_app/docker-compose.yml down --remove-orphans

Der Befehl stoppt und entfernt den Container sowie das zugehörige Compose-Netzwerk. Die Testergebnisse im lokalen Ordner `results/` bleiben erhalten und können weiterhin im Browser geöffnet werden.

Repository-Struktur

Die wichtigsten Verzeichnisse sind:

.github/
└── workflows/     # Enthält den GitHub-Actions-Workflow

tests/
├── data/          # CSV- und Excel-Testdaten
├── resources/     # Keywords und Locators
├── robot/         # ausführbare Suites
└── variables/     # Umgebungswerte und Browserkonfiguration

scripts/
├── wait_for_url.py  # wartet auf die Erreichbarkeit des Webshops
├── reporting/       # Aufbau der GitHub-Pages-Seite
└── test_support/    # Python-Helfer für Tests

webshop_app/       # Docker-Compose-Konfiguration für OWASP Juice Shop

Die Struktur trennt fachliche Tests, technische Browserinteraktion, Testdaten und Umgebungskonfiguration. Dadurch wird sichtbar, warum eine Datei geändert wird. Eine neue Journey gehört in tests/robot/, ein geänderter Selektor in tests/resources/ und eine neue Datenkombination in tests/data/.

Architektur und Aufbau von Robot-Tests verstehen

Ein Robot-Projekt besteht meist aus vier Ebenen:

• Eine Suite gruppiert zusammengehörige Testfälle.
• Ein Testfall beschreibt ein erwartetes Verhalten.
• Ein Keyword führt eine wiederverwendbare Aktion oder Prüfung aus.
• Ein Locator identifiziert ein Element im Browser.

Diese Ebenen werden im Repository auf unterschiedliche Dateitypen verteilt.

Eine .robot-Datei ist eine ausführbare Test-Suite. Sie wird mit dem robot-Befehl gestartet und importiert über Resource die Bausteine, die sie für den Testablauf benötigt. Da die Testfälle vor allem das erwartete Verhalten beschreiben, können sie auch gemeinsam mit dem Fachbereich entwickelt und geprüft werden.

Eine .resource-Datei dient als gemeinsamer Baukasten. Sie bündelt wiederverwendbare Keywords, Variablen und Locators. Die Suite ruft ein fachlich benanntes Keyword auf, während das Keyword bei Bedarf den passenden Locator und die technischen Browseraktionen verwendet. Dadurch bleiben die Testfälle lesbar und Browserdetails zentral verwaltet.

Locators sollten deshalb nicht direkt in fachlichen Suite-Dateien liegen. Ändert sich ein Attribut oder die CSS-Struktur des Webshops, sollte nur die zuständige Resource-Datei angepasst werden müssen.

Eine .py-Datei ergänzt Robot Framework bei klar abgegrenzten technischen Aufgaben. Sie kann beispielsweise CSV-Daten einlesen, Eingaben validieren und die aufbereiteten Werte als Robot-Variablen bereitstellen. Auch Hilfsskripte wie ein Readiness-Check für die Anwendung können in Python umgesetzt werden. Die .robot-Suite muss die interne Python-Implementierung dabei nicht kennen.

Der Zusammenhang lautet daher:

• .robot beschreibt Testfälle und deren Ablauf.
• .resource enthält wiederverwendbare Testschritte, Locators und technische Browserinteraktionen.
• .py übernimmt Aufgaben, für die Python besser geeignet ist, etwa komplexere Datenverarbeitung oder technische Hilfsfunktionen.

Die vier wichtigsten Abschnitte einer Robot-Datei

Robot-Dateien sind tabellarisch aufgebaut. Zellen werden durch mindestens zwei Leerzeichen oder einen Tab getrennt. Für Einsteiger sind vier Abschnitte besonders wichtig.

*** Settings ***

Im Settings-Abschnitt werden Libraries, Resource-Dateien und Variable-Dateien importiert. Außerdem lassen sich unter anderem Dokumentation, Setup, Teardown und Test-Templates konfigurieren.

*** Settings ***
Library             DataDriver
Resource            ${CURDIR}/../resources/juice_shop.resource
Test Setup          Open Shop Homepage
Test Teardown       Handle Test Cleanup
Test Template       Search Row Should Match

Library lädt eine externe Testbibliothek. Resource bindet projektspezifische Keywords und Variablen ein. Mit Test Setup und Test Teardown werden Schritte festgelegt, die vor beziehungsweise nach jedem Test ausgeführt werden. Ein Test Template definiert ein Keyword, das für mehrere Datenzeilen verwendet wird.

*** Variables ***

Dieser Abschnitt enthält skalare Variablen, Listen und Dictionaries. Die Schreibweise beschreibt vor allem, wie Robot Framework den Wert beim Aufruf verwendet:

• ${BASE_URL} übergibt einen Wert oder ein Objekt als Ganzes.
• @{ROWS} erweitert eine Liste in einzelne Werte.
• &{VIEWPORT} erweitert ein Dictionary beispielsweise zu benannten Argumenten.

Auch eine skalare Variable wie ${ROWS} kann intern eine Python-Liste enthalten.

Variablen sollten Bedeutung transportieren. Nicht jedes Literal muss ausgelagert werden. Eine Base URL, ein Browser-Timeout oder ein fachlich relevanter Erwartungswert verdienen einen sprechenden Namen. Ein einmaliger, unkritischer Wert kann dagegen direkt im Keyword stehen.

*** Test Cases ***

Im Test-Cases-Abschnitt stehen die ausführbaren Tests. Ein guter Testname beschreibt das geprüfte Verhalten und möglichst auch das erwartete Ergebnis.

Der Testkörper sollte kurz genug bleiben, damit der Ablauf sowohl im Quelltext als auch im Robot-Report verständlich ist. Technische Details wie CSS-Selektoren, Browserinitialisierung oder komplexe Datenkonvertierungen gehören normalerweise nicht direkt in den Testfall.

*** Keywords ***

Im Keywords-Abschnitt werden wiederverwendbare Abläufe definiert. Keywords können Argumente annehmen, Werte zurückgeben, Kontrollstrukturen enthalten und weitere Keywords aufrufen.

Ein Keyword sollte eine klare Verantwortung besitzen. Namen wie Do Login Things verstecken die eigentliche Absicht. Namen wie Submit Login Credentials oder Failed Login Should Be Visible beschreiben dagegen konkret, was ausgeführt oder geprüft wird.

Robot Framework unterscheidet in diesem Projekt drei Arten von Keywords:

• BuiltIn-Keywords gehören zum Kern von Robot Framework und stehen ohne zusätzlichen Library-Import zur Verfügung. Beispiele sind Convert To Integer, Wait Until Keyword Succeeds und Run Keyword And Ignore Error.
• Library-Keywords werden von importierten Testbibliotheken bereitgestellt. Die Browser-Library liefert beispielsweise Type Text, Press Keys und Close Browser. RPA.Excel.Files ergänzt Keywords wie Open Workbook und Read Worksheet.
• User-Keywords werden im Projekt selbst definiert, meist in .resource-Dateien. Beispiele sind Search For Product, Search Results Should Match und Open Shop Homepage. Sie kombinieren technische Schritte zu einer projektspezifischen und fachlich verständlichen Aktion.

Ein Test wird dadurch schichtweise ausgeführt:

Search Keywords From CSV With Python Reader
└── Search Results Should Match       # User-Keyword
    ├── Convert To Integer            # BuiltIn-Keyword
    ├── Search For Product            # User-Keyword
    │   ├── Type Text                 # Library-Keyword
    │   └── Press Keys                # Library-Keyword
    └── Catalog Should Show Exact Product Count

Diese Kette ist ein Kernprinzip von Robot Framework. Ein Testfall beschreibt das erwartete Verhalten. User-Keywords bilden die projektspezifische Sprache. Library-Keywords führen die technische Interaktion mit Browser, Dateien oder anderen Systemen aus.

Robot Framework selbst muss dabei weder den OWASP Juice Shop noch dessen HTML-Struktur kennen. Das Framework löst die Keyword-Aufrufe auf, steuert die Ausführung und erstellt anschließend Logs und Reports.

Setup und Teardown: Jeder Test startet definiert

Setup und Teardown sind zwei zentrale Suite-Einstellungen, die in allen Varianten gleich bleiben. Sie verhindern, dass jeder Test denselben technischen Rahmen wiederholt. In den Suites gelten:

Test Setup       Open Shop Homepage
Test Teardown    Handle Test Cleanup

Open Shop Homepage startet einen Browser, legt einen neuen Context an, öffnet die Seite, schließt Startdialoge und wartet auf den Katalog. Handle Test Cleanup erstellt bei einem Fehler einen Screenshot und beendet die Browser-Session.

Handle Test Cleanup
    Take Failure Screenshot
    Close Browser Session

Der Teardown wird auch nach einem fehlgeschlagenen Test ausgeführt. Das ist wichtig, weil gerade Fehlerfälle Browserprozesse, Dateien oder Testdaten hinterlassen können. Cleanup darf deshalb möglichst wenig neue Fehler erzeugen. Das Projekt verwendet beim Schließen Run Keyword And Ignore Error, damit ein bereits geschlossener Browser das ursprüngliche Testergebnis nicht überdeckt.

Optional kann die Suite Videos aufzeichnen. Dazu werden beim Start Variablen überschrieben:

python -m robot \
  --outputdir results \
  --variable RECORD_VIDEO:True \
  --variable HEADLESS:False \
  tests/robot

Videos sind hilfreich bei schwer reproduzierbaren UI-Problemen, erhöhen aber Laufzeit und Artefaktgröße. Für jeden normalen Lauf sind Screenshots meist ausreichend.

Browseraktionen in einer Resource-Datei kapseln

Die Datei juice_shop.resource enthält die technische Umsetzung des Keywords Search Results Should Match, das alle drei datengetriebenen Suiten in den folgenden Kapiteln aufrufen. Sie zentralisiert wiederverwendbare Browseraktionen und Locators, damit die Suite keine CSS-Selektoren kennen muss.

*** Variables ***
${SEARCH_INPUT_LOCATOR}    css=app-mat-search-bar input:visible

*** Keywords ***
Search For Product
    [Documentation]    Search the catalog for the provided term and wait for the matching result state.
    [Arguments]    ${search_term}
    Ensure Search Input Is Ready
    Type Text    ${SEARCH_INPUT_LOCATOR}    ${search_term}
    Press Keys    ${SEARCH_INPUT_LOCATOR}    Enter
    Wait For Search State    ${search_term}

Search Results Should Match
    [Documentation]    Search for a term and verify that the visible result count matches the expectation.
    [Arguments]    ${search_term}
    ...    ${expected_result_count}
    ${expected_count}=    Convert To Integer    ${expected_result_count}
    Search For Product    ${search_term}
    IF    $expected_count == 0
        Wait Until Keyword Succeeds    10x    300ms    No Results Message Should Be Visible
    ELSE
        Wait Until Keyword Succeeds    10x    300ms    Catalog Should Show Exact Product Count    ${expected_count}
    END

Search Results Should Match verbindet alle drei Keyword-Arten. Convert To Integer und Wait Until Keyword Succeeds sind BuiltIn-Keywords. Search For Product und Catalog Should Show Exact Product Count sind User-Keywords. Type Text und Press Keys stammen aus der Browser-Library.

Die Browser-Library wartet bei vielen Browseraktionen automatisch darauf, dass Elemente verwendbar sind. Wait Until Keyword Succeeds wird hier gezielt für einen anwendungsspezifischen Zustand eingesetzt: Die Anzahl der sichtbaren Produkte kann sich nach der Suche asynchron ändern. Daraus folgt nicht, dass jede Browseraktion zusätzlich in eine Retry-Schleife gehört.

CSV-Daten mit Python validieren und bereitstellen

search_cases.py verwendet Pythons eingebaute csv-Bibliothek, um die Datei search_keywords.csv einzulesen und die Variable ROWS für Robot Framework bereitzustellen. Das folgende Snippet zeigt die Verbindung zwischen Python und Robot Framework:

import csv
from pathlib import Path

def _load_rows(data_path):
    with data_path.open(encoding="utf-8", newline="") as handle:
        return [
            {"input": row["Input"], "expectation": int(row["Expectation"])}
            for row in csv.DictReader(handle)
        ]

data_path = Path("tests/data/search_keywords.csv")
ROWS = _load_rows(data_path)

In der tatsächlichen Datei prüft der Reader zusätzlich die Spaltennamen und Werte. Das Beispiel zeigt die grundsätzliche Verbindung: Python liest und formt die Daten, Robot Framework iteriert über die Datensätze und das Resource-Keyword prüft das Verhalten des Webshops.

Die drei Dateitypen bilden damit eine klare Arbeitsteilung. Die Robot-Suite beschreibt, was geprüft wird. Die Resource-Datei definiert, wie die fachlichen Aktionen im Browser ausgeführt werden. Die Python-Datei bereitet die benötigten Testdaten vor.

Datengetriebene Tests mit Robot Framework

Datengetriebene Tests trennen Testlogik und Eingabekombinationen. Statt denselben Suchablauf für apple, banana, ein Leerzeichen und mango zu kopieren, wird ein Keyword mit mehreren Datensätzen ausgeführt.

Das Repository demonstriert drei Wege, die Daten bereitzustellen. In allen drei Varianten erhält `Search Results Should Match` einen Suchbegriff und die erwartete Anzahl sichtbarer Ergebnisse. Unterschiede bestehen darin, wie die Daten zu Robot Framework gelangen und wie die einzelnen Datensätze im Report erscheinen.

• Methode 1: Robot Framework DataDriver
• Methode 2: Python-Reader mit Python-Hilfsdatei
• Methode 3: RPA Framework mit RPA.Excel.Files

Methode 1: Robot Framework DataDriver

search_method_1_DataDriver.robot verwendet die DataDriver-Library. Die CSV-Spalten werden an ein Test-Template übergeben. Aus jeder Datenzeile entsteht ein eigener Robot-Test.

Diese Methode eignet sich, wenn die CSV-Datei bereits der von DataDriver erwarteten Struktur entspricht und die Werte direkt an ein Robot-Test-Template übergeben werden können. Die Überschriften der Daten-Spalten müssen zu den Argumenten des Template-Keywords passen. DataDriver liest die Datei beim Vorbereiten der Suite und erzeugt aus jeder Datenzeile einen Test, der die Spaltenwerte an das Template-Keyword übergibt. Ein separater Python-Reader ist dafür nicht nötig.

*** Settings ***
Library             DataDriver
...                     file=${CURDIR}/../data/search_keywords_datadriver.csv
Test Template       Search Row Should Match

*** Test Cases ***
Search for "${keyword}" should return ${amount_of_results} results
    keyword    results

*** Keywords ***
Search Row Should Match
    [Arguments]    ${keyword}
    ...    ${amount_of_results}
    Search Results Should Match    ${keyword}    ${amount_of_results}

Das Template-Keyword Search Row Should Match ist bewusst in derselben .robot-Suite definiert. DataDriver benötigt dort die Argumentnamen, um die Spalten der Datendatei zuzuordnen. Das lokale Wrapper-Keyword delegiert die fachliche Prüfung anschließend an Search Results Should Match aus der Resource-Datei.

DataDriver liefert außerdem die beste Granularität im Report. Aus den sechs Datensätzen in search_keywords_datadriver.csv entstehen sechs eigenständige Tests. Jeder Test erhält durch Setup und Teardown eine neue Browser-Session. Das verbessert Isolation, kostet aber mehr Laufzeit.

Methode 2: Python-Reader für CSV

Diese Methode eignet sich, wenn vollständige Kontrolle darüber benötigt wird, wie CSV-Daten gelesen werden, bevor Robot sie erhält. csv.DictReader ordnet jede Zeile ihren Spaltenüberschriften zu. Der Python-Helfer kann erforderliche Spalten prüfen, Werte in den passenden Typ umwandeln, Eingaben normalisieren oder eine klare Fehlermeldung für ungültige Daten ausgeben.

Die Suite search_method_2_Python_Reader.robot  importiert zwei unterschiedliche Bausteine. Die Resource-Datei stellt die Keywords für die UI-Prüfung bereit. Die Python-Datei liefert die aus der CSV-Datei gelesenen Daten als ${ROWS}.

*** Settings ***
Documentation       Search coverage for OWASP Juice Shop using a Python-backed CSV variable file.
...                 Search method 2: Python variable file plus csv.DictReader.
...                 The suite keeps one browser session open while it iterates through search_keywords.csv.

Resource            ${CURDIR}/../resources/juice_shop.resource
Variables           ${CURDIR}/../../scripts/test_support/search_cases.py

Test Setup          Open Shop Homepage
Test Teardown       Handle Test Cleanup


*** Test Cases ***
Search Keywords From CSV With Python Reader
    [Documentation]    Verify that every search_keywords.csv row produces the expected result.
    Search Every CSV Row


*** Keywords ***
Search Every CSV Row
    [Documentation]    For every row in the CSV file, perform a search and verify the result.
    FOR    ${row}    IN    @{ROWS}
        Search Results Should Match    ${row}[input]    ${row}[expectation]
    END

Der Test Case ruft zunächst `Search Every CSV Row` auf. Dieses Keyword durchläuft die importierten Datenzeilen und übergibt pro Zeile Suchbegriff und Erwartungswert an `Search Results Should Match`. Die Suite enthält weder Browser-Locators noch die Logik zum Einlesen der CSV-Datei.

Das Python-Skript liest und verarbeitet die CSV-Datei:

with data_path.open(encoding="utf-8", newline="") as handle:
    reader = csv.DictReader(handle)
    if reader.fieldnames != list(EXPECTED_COLUMNS):
        raise ValueError("Unexpected CSV columns")

    rows = [
        {
            "input": row["Input"] or "",
            "expectation": int(row["Expectation"] or ""),
        }
        for row in reader
    ]

Diese Variante bietet die meiste Kontrolle über Validierung und Normalisierung. Der Nachteil ist zusätzlicher Python-Code. Außerdem erscheint die gesamte Schleife als ein Robot-Test. Schlägt eine Zeile fehl, stoppt die Schleife in der aktuellen Implementierung beim ersten Fehler.

Methode 3: RPA Framework mit RPA.Excel.Files

search_method_3_RPA_Excel_Files.robot liest eine Excel-Arbeitsmappe direkt.

Diese Methode eignet sich, wenn die Quelldaten eine Excel-Arbeitsmappe sind. Excel ist sinnvoll, wenn Fachbereiche Daten bereits in Arbeitsmappen pflegen, mehrere Tabellenblätter benötigt werden oder CSV nicht ausreicht. Für wenige einfache Werte ist Excel meist unnötig schwergewichtig. Die RPA.Excel.Files-Bibliothek kann eine Arbeitsmappe öffnen, ein Arbeitsblatt auswählen und Zeilen anhand der Überschriftenzeile als Dictionaries zurückgeben.

Die Schleife verwendet zusätzlich `Run Keyword And Continue On Failure`. Anders als bei Methode 2 stoppt eine fehlgeschlagene Zeile die restliche Prüfung nicht. Robot Framework prüft weiter alle Datenzeilen, markiert den gesamten Test am Ende jedoch als fehlgeschlagen. Die Details aller Zeilen erscheinen im selben Testergebnis.

*** Keywords ***
Load Search Rows From Excel
    Open Workbook    ${SEARCH_EXCEL_FILE}
    ${rows}=    Read Worksheet    name=${SEARCH_WORKSHEET_NAME}    header=${TRUE}
    Close Workbook
    RETURN    ${rows}

Welche Methode passt wann?

Die Entscheidung sollte nicht allein vom bevorzugten Dateiformat abhängen. Wichtig sind auch Fehlerdiagnose, Testisolation, Laufzeit und die Frage, wer die Daten pflegt.

Tests in GitHub Actions ausführen

Robot Framework passt gut in CI, weil ein Testlauf über einen einzelnen Befehl gestartet wird und standardisierte HTML- sowie XML-Ergebnisse erzeugt. Der vorgesehene Ablauf des Projekts ist im Workflow .github/workflows/ui-tests.yml beschrieben. Bei Pull Requests und Pushes auf main führt der Workflow Folgendes aus:

1. Repository auschecken und Python einrichten.
2. Projektabhängigkeiten installieren.
3. Robot-Dateien mit Robocop prüfen.
4. Browser-Library initialisieren.
5. Juice Shop mit Docker Compose starten.
6. Mit wait_for_url.py auf die Bereitschaft des Webshops warten.
7. Robot-Suites ausführen.
8. results/ als Artefakt hochladen.
9. Eine statische Seite aus denselben Robot-Ergebnissen erzeugen.
10. Die Seite bei Pushes auf main über GitHub Pages veröffentlichen.
11. Container stoppen.

Wichtig ist die Ähnlichkeit zwischen lokalem und CI-Ablauf. Je weniger Sonderlogik die Pipeline enthält, desto leichter lassen sich Fehler reproduzieren. Die Anwendung wird pro Lauf neu gestartet, wodurch jeder Build einen bekannten Ausgangszustand erhält.

Das Skript scripts/reporting/build_pages_site.py kopiert report.html, log.html, output.xml und weitere Ergebnisdateien in ein statisches Verzeichnis. Eine kleine Startseite verlinkt anschließend auf die nativen Robot-Berichte. GitHub Pages ist damit nur die Veröffentlichungsfläche, nicht das Testsystem selbst. Dafür muss in den Repository-Einstellungen unter Pages als Quelle GitHub Actions aktiviert sein. Bitte darauf achten: Veröffentlichte Robot-Reports und Fehler-Screenshots können dabei Eingaben und Diagnosedaten offenlegen. Berichte, die mit echten Zugangsdaten oder sensiblen Daten erzeugt wurden, sollten deshalb nie veröffentlicht werden.

Stärken und Grenzen von Robot Framework

Die größte Stärke ist nicht eine vermeintlich natürliche Sprache, sondern die kontrollierte Abstraktion. Fachliche Tests können kurz bleiben, während technische Details in Libraries und Resources liegen. Weitere Vorteile sind plattformunabhängige Ausführung, erweiterbare Python-Schnittstellen, Daten-Templates und sofort verfügbare Reports.

Die Lesbarkeit kann allerdings kippen. Zu große Keywords verstecken wichtige Testschritte. Zu viele kleine Keywords erzeugen einen tiefen Log-Baum. Ressourcen mit langen Importketten erschweren die Suche nach der tatsächlichen Implementierung. Gute Robot-Suites brauchen deshalb dieselbe Architekturdisziplin wie normaler Anwendungscode.

Auch die Aussage, Robot Framework erfordere keine Programmierkenntnisse, gilt nur für einfache Fälle. Für robuste UI-Tests sind Kenntnisse in HTML, CSS, Browserzuständen, Datenmodellierung, Python und CI sehr nützlich. Robot Framework senkt die Einstiegshürde, ersetzt diese Kompetenzen aber nicht.

Für sehr algorithmische Logik ist Python oft die bessere Ebene. Robot sollte die fachliche Orchestrierung und gut lesbare Assertions behalten. Komplexe Parser, Datenkonvertierungen oder technische Integrationen gehören in kleine, getestete Libraries oder Hilfsskripte.

Nächste Schritte

Das Repository bietet mehrere Erweiterungspunkte zum Lernen:

• Testdaten ändern.
• Einen Test zum Entfernen von Artikeln aus dem Warenkorb schreiben.
• Tests mit Tags versehen und Smoke- sowie Regression-Läufe trennen.
• Checkout-Tests ergänzen, ohne ein einziges übergroßes Complete Checkout-Keyword zu bauen.

Jede Erweiterung sollte dieselbe Grundregel beibehalten: Testfälle beschreiben Verhalten, Resources kapseln Browserdetails, Daten bleiben außerhalb des Ablaufs und die Pipeline führt möglichst dieselben Befehle aus wie die lokale Entwicklung.

Weiterführende Quellen

Die folgenden Quellen vertiefen die beschriebenen Konzepte und Konventionen.

• Robot Framework User Guide
• Robot Framework Browser Library
• Robot Framework DataDriver
• Robot Framework Style Guide
• RPA.Excel.Files
• Robocop
• Github RobotFramework Python Tutorial