Robot Framework als reine Domain-Specific Language

TL;DR: Robot Framework lohnt sich auch ohne seine Standard-Libraries. Im Pattern «RF Thin Layer + Pure Python Keywords» wird RF nur als DSL-Orchestrierungsschicht verwendet, alle Keywords sind reine Python-Funktionen mit direktem Zugriff auf das volle Python-Ökosystem. Vorteile: voller IDE-Debugger, kein Library-Wrapper-Bottleneck, geringes Lock-in, fachliche Lesbarkeit für Auditoren. Kostet höhere Python-Kompetenz und Architektur-Disziplin im Team.

Lesedauer ca. 11 Min · Stand: 2026-04

Robot Framework wird oft mit seinen Standard-Libraries gleichgesetzt: SeleniumLibrary, Browser, BuiltIn, RequestsLibrary, DatabaseLibrary. In dieser Lesart ist RF ein Test-Framework mit eigenem Ökosystem an Test-Werkzeugen. Diese Lesart funktioniert für kleine Suites — und hält bei zehntausenden Tests, heterogenen Tech-Stacks und langen Lebenszyklen nicht stand.

Es gibt eine andere Lesart, die seit Jahren in regulierten Branchen (Finance, Pharma, Sozialversicherung, Behörden) funktioniert: Robot Framework als reine DSL-Orchestrierungsschicht — und alle Keywords als pure Python-Funktionen.

Das Muster

Drei Regeln definieren das Pattern:

RF nur als DSL. .robot-Dateien beschreiben Test Cases, Test-Suites, Tags — sie sind Spezifikation, lesbar für Fachtester und Prüfer.
Keine RF-Libraries in .robot-Dateien. Kein Library SeleniumLibrary, kein Should Be Equal, kein Sleep, kein Log.
Alle Keywords in Python, mit direktem Zugriff auf Playwright, requests, sqlalchemy, paramiko, pyrfc, zeep — was immer das Python-Ökosystem bietet.

Konsequent durchgezogen heisst das: ein fachliches Keyword wie Prüfe Kundenmaske Vollständig ruft in Python zehn oder mehr asserts aus, von denen die .robot-Datei nichts sieht. Die Test-Spezifikation bleibt fachlich, die Mechanik liegt vollständig in Python.

Was man gewinnt

Volles Python-Ökosystem. Wenn Playwright eine neue Trace-Funktion bringt, ist sie sofort nutzbar. Bei einem RF-Library-Wrapper wartet man auf den Maintainer. Das Wartebottleneck verschwindet komplett, weil man direkt gegen die Library ohne Zwischenschicht arbeitet. Das Gleiche gilt für requests (REST), zeep (SOAP), sqlalchemy (Datenbank), paramiko (SSH), pika (RabbitMQ), pyrfc/ctypes (SAP). Jede Schnittstelle, für die es eine Python-Library gibt, lässt sich nativ ansprechen.

Echtes Debugging. Python-Keywords laufen mit Breakpoints, Step-Through, pdb, IDE-Inspektion. Die übliche RF-Variante mit Standard-Libraries verliert diese Tiefe — Stacktraces werden gestrippt, Fehler-Lokalisierung läuft über Library-Hooks. Im Thin-Layer-Pattern bleibt der volle Python-Stack sichtbar.

Lesbarkeit für Fachtester und Auditoren. Genau weil die Keywords fachlich abstrahieren, bleiben die .robot-Dateien menschenlesbar — auch für Mitarbeitende ohne Programmiererfahrung. Das ist nicht «Testen ohne Programmierkenntnisse» — diese Behauptung ist seit Record-and-Replay-Tools von 2005 unbelegt. Es ist «nicht jeder muss Python können». Die Trennung von Spezifikation (.robot) und Mechanik (Python) wird zum Designprinzip.

Audit-Trail by Default. RF erzeugt output.xml und log.html aus jedem Lauf. Das sind keine Add-ons — sie sind nativ. Für regulierte Branchen (FINMA, GxP, behördliche Audits) ist das exakt die Beweiskette, die Prüfer verlangen. Fachliche Keyword-Namen tauchen im Log auf, der Test-Verlauf ist nachvollziehbar dokumentiert.

Geringstes Lock-in. Python-Keywords sind framework-agnostisch — wenn RF eines Tages weicht, sind die Keywords mit minimalem Aufwand auf pytest umstellbar (eine Funktion bleibt eine Funktion). Bei einem Standard-RF-Setup mit SeleniumLibrary und BuiltIn-Aufrufen verlangt diese Migration eine vollständige Test-Neuschrift.

Open Source und keine Lizenzkosten. Robot Framework steht unter Apache 2.0, alle gängigen Python-Libraries unter Open-Source-Lizenzen. Lizenzkosten für Standard-Test-Tools liegen in vergleichbarem Enterprise-Setup oft im fünf- bis sechsstelligen Bereich pro Jahr — entfallen hier komplett.

Was es kostet

Performance-Overhead bleibt. RF parst und reportet jeden Schritt. Reines pytest ist etwa 15–25 % schneller. Bei nächtlichen Regressionstests über parallele CI-Jobs spielt das praktisch keine Rolle. In Microservice-CI-Pipelines mit Sub-Sekunden-Anspruch tut es das durchaus. Die Frage ist, ob der RF-Overhead in der konkreten Pipeline relevant wird.

Höheres Python-Niveau im Team. Standard-RF lässt sich mit Library SeleniumLibrary und vorgefertigten Keywords starten — das Team kommt mit RF-Syntax-Kenntnissen weit. Im Thin-Layer-Pattern braucht das Team Python-Kompetenz von Anfang an: Klassen, Type Hints, Helper, Fixtures, Datenmodelle. Wer das Pattern wählt, akzeptiert eine höhere Einstiegshürde — und gewinnt im Gegenzug Tiefenkontrolle.

Kuratierte Keyword-Bibliothek nötig. Damit Fachtester sinnvoll arbeiten können, muss jemand die Keywords sauber benennen, gruppieren und dokumentieren. Ohne diese Kuration entstehen tausende Mikro-Keywords mit überlappenden Namen — die .robot-Datei wird zur Hieroglyphensammlung.

XML-Output als Skalierungsgrenze. RF schreibt Outputs als XML. Ab Suite-Grössen jenseits 10’000 Tests in einem Lauf wird das Parsen langsam. Modulare Test-Architektur (kleine Suites, parallele Jobs, getrennte Outputs) entschärft das, kostet aber Disziplin im Suite-Schnitt.

Wie der Aufbau aussieht

Eine typische Projekt-Struktur:

project/
├── tests/
│   ├── suites/              # .robot files (Test-Spezifikation)
│   │   ├── kunden/
│   │   │   ├── stammdaten.robot
│   │   │   └── pflege.robot
│   │   └── auftraege/
│   ├── keywords/            # Python @keyword functions (Mechanik)
│   │   ├── kundenmaske.py
│   │   └── auftragsmaske.py
│   ├── clients/             # Pure Python: API/DB/SAP-Clients
│   │   ├── kunden_client.py
│   │   └── sap_rfc_client.py
│   └── fixtures/            # Setup/Teardown, Test-Daten
└── pyproject.toml

Drei Schichten, klar getrennt:

suites/ — .robot-Dateien mit fachlichen Test Cases. Lesbar für Fachtester. Keine technischen Details.
keywords/ — Python-Module mit @keyword-dekorierten Funktionen. Bündelt Asserts, kombiniert Client-Aufrufe, formuliert fachliche Operationen.
clients/ — reine Python-Clients gegen die Schnittstellen des System under Test. Kein RF-Bezug, einsetzbar auch ausserhalb von Tests.

Diese Schichten-Trennung ist nicht neu — sie folgt dem Hexagonal-Architecture-Prinzip auf der Test-Seite. Sie ist aber im Standard-RF-Setup ungewöhnlich, weil dort RF-Libraries die Client- und Keyword-Schicht oft vermischen.

Codebeispiel

Ein fachliches Keyword, das mehrere Asserts kapselt:

# tests/keywords/kundenmaske.py
from robot.api.deco import keyword
from tests.clients.kunden_client import KundenClient

@keyword("Pruefe Kundenmaske Vollstaendig")
def pruefe_kundenmaske_vollstaendig(kunde_id: str) -> None:
    daten = KundenClient().lesen(kunde_id)
    assert daten.id == kunde_id, f"ID-Mismatch: {daten.id}"
    assert daten.status == "aktiv", f"Status: {daten.status}"
    assert daten.adresse.plz, "PLZ leer"
    assert daten.adresse.strasse, "Strasse leer"
    assert daten.kontakt.email, "E-Mail leer"
    # weitere fachliche Asserts ...

Ein Keyword, das Workflows komponiert:

@keyword("Auftrag Anlegen Mit Position")
def auftrag_anlegen_mit_position(kunde_id: str, artikel_nr: str, menge: int) -> str:
    client = AuftragsClient()
    auftrag_id = client.neu(kunde_id)
    client.position_hinzufuegen(auftrag_id, artikel_nr, menge)
    client.speichern(auftrag_id)
    return auftrag_id

Die .robot-Datei kennt nur die fachlichen Keywords:

*** Settings ***
Library    tests.keywords.kundenmaske
Library    tests.keywords.auftragsmaske

*** Test Cases ***
Auftrag Mit Bestehendem Kunden Anlegen
    [Tags]    smoke    auftraege
    Pruefe Kundenmaske Vollstaendig    K-12345
    ${auftrag_id}=    Auftrag Anlegen Mit Position    K-12345    ART-789    3
    Pruefe Auftrag Gespeichert    ${auftrag_id}

Wenn KundenClient morgen von SOAP auf REST umzieht, bleibt der .robot-Test unverändert. Wenn die Maske ein neues Pflichtfeld bekommt, wird ein einzelnes Assert in pruefe_kundenmaske_vollstaendig ergänzt — der Test selbst muss nicht angefasst werden.

Vergleich gegen Standard-RF

Kriterium	Standard-RF (mit Libraries)	RF Thin Layer + Pure Python
Keyword-Quelle	RF-Libraries (SeleniumLib, BuiltIn)	Pure Python (Playwright, requests, …)
Debugging	Stacktraces gestrippt, Library-Hooks	Voller IDE-Debugger, `pdb`, Step-Through
Neue Library-Features	Warten auf Wrapper-Update	Sofort verfügbar
Ökosystem-Tiefe	RF-Plugin-Stand	Python-Ökosystem-Stand
Lock-in	Hoch (RF-Library-spezifisch)	Gering (framework-agnostisch)
Performance	RF-Overhead	RF-Overhead (gleich)
Lernkurve Team	RF + Library-Syntax	RF + Python-Architektur
Audit-Trail	output.xml / log.html	output.xml / log.html (gleich)
Migration zu pytest	Test-Neuschrift	Keyword-Reuse

Wann (und wann nicht) sich der Aufwand lohnt

Das Pattern entfaltet seine Stärken bei drei Bedingungen:

Lange Lebensdauer der Test-Suite. Ein Pilotprojekt mit 100 Tests rechtfertigt den Architektur-Aufwand kaum. Eine Test-Suite, die zehn Jahre laufen soll, schon.
Heterogene Technologien im System under Test. Wenn Tests gegen Web, REST, SOAP, Datenbank, SAP, Message Queue und Legacy-Systeme laufen müssen, ist das volle Python-Ökosystem unschätzbar. RF-Libraries decken nicht alle Layer.
Regulatorische Nachweispflicht. FINMA-Prüfungen, GxP, behördliche Audits — überall, wo Tests als Dokumentation für Prüfer dienen, zahlt sich die fachliche Keyword-Lesbarkeit aus.

Was es nicht ist:

Kein Verzicht auf Robot Framework. Die DSL bleibt zentral. Wer RF komplett weglassen will, ist bei pytest oder Behave besser aufgehoben.
Kein universelles Heilmittel. Kleine Suites profitieren wenig vom Architektur-Aufwand.
Kein Ersatz für Test-Disziplin. Architektur folgt Disziplin, nicht umgekehrt. Ein Team ohne klare Test-Strategie wird auch mit dem besten Pattern keine wartbare Suite produzieren.

Migration aus einem bestehenden Standard-RF-Setup verläuft schrittweise: neue Tests im Pattern schreiben, bestehende Library-Aufrufe an natürlichen Schnittstellen durch Python-Keywords ersetzen, Test-Reuse über Komponenten ausbauen. Ein Big-Bang ist riskant und meist unnötig — die zwei Patterns vertragen sich in einer Suite, solange die Spielregeln klar sind.

Quellen

Sie überlegen, RF im Thin-Layer-Pattern aufzubauen oder eine bestehende Test-Suite umzubauen? Im UTAA-Workshop legen wir Architektur, Keyword-Design und Tooling projektspezifisch fest. Mehr zur Methode oder direkt anfragen.