Die Robot-Framework-Identitätskrise

TL;DR: Robot Framework steht in einer fundamentalen Spannung: lesbare keyword-getriebene DSL gegen schleichende Evolution zur Programmiersprache. Seit Version 4.0 sind IF/ELSE, WHILE, TRY/EXCEPT, VAR und GROUP eingeführt. RF-Schöpfer Pekka Klärck hat die Spannung selbst eingeräumt: User fordern Funktionen, die in Python längst verfügbar wären. Dieser Artikel ordnet die sieben häufigsten Community-Kritikpunkte, die Evolution seit 2021 — und den Mittelweg, den erfahrene Nutzer als pragmatisch beschreiben.

Lesedauer ca. 12 Min · Stand: 2026-04

Robot Framework hatte 2008 einen klaren Charakter: tabellarische, lesbare Testdaten in Plain-Text-Dateien, ergänzt um Keyword-Libraries in Python. Das war eine DSL für Testbeschreibung, keine Programmiersprache. Knapp zwanzig Jahre später ist davon weniger geblieben, als die Marketing-Seite suggeriert. Wer 2025 ein RF-Projekt aufsetzt, findet eine Sprache vor, die getypte Variablen, Conditionals, zwei Loop-Typen, Exception-Handling, Inline-Python und benannte Code-Blöcke kennt — also alles, was eine ausgewachsene Programmiersprache ausmacht. Die Community ist sich uneinig, ob das ein Fortschritt ist.

Was Befürworter loben

Stärke	Inhalt
HTML-Reporting	Out-of-the-box, hierarchisch, detailliert — selbst Kritiker räumen die Überlegenheit ein
Keyword-Driven	Einstieg auch für Tester ohne Programmierhintergrund möglich, sofern eine Keyword-Library aufgebaut ist
Library-Ökosystem	SeleniumLibrary, Browser (Playwright), Appium, Requests, Database, SSH — Web, API, Mobile, Desktop unter einem Dach
RF Foundation	70+ Mitgliedsorganisationen, stabile Governance, aktive Weiterentwicklung
Slack-Community	Konsistent als hilfsbereit und antwortfreudig beschrieben
Standardisierung	Verschiedene Automatisierungsarten in einem einheitlichen Framework

Diese Stärken sind unstrittig. Die Diskussion entzündet sich an den Kosten, die mit der Sprache selbst verbunden sind.

Sieben häufige Kritikpunkte

Aufgereiht nach Frequenz in Community-Diskussionen (RF Forum, Reddit r/QualityAssurance, Hacker News, HitchDev).

Unnötige Abstraktionsschicht. Der meistgenannte Vorwurf. Reddit-Threads bringen es auf den Punkt: «It adds an unnecessary layer. It’s Python but without Python.» Hacker-News-Diskussionen erwähnen, Tests direkt in einer Programmiersprache zu schreiben wäre einfacher gewesen. Keyword-Wiederverwendung wird in Forumsstichproben als zweischneidig beschrieben — wenige vielgenutzte Keywords, langer Tail von Einmal-Keywords.

Nicht-Programmierer schreiben selten Tests. RFs Kernversprechen — Nicht-Techniker lesen und schreiben Tests — materialisiert sich nach mehreren Erfahrungsberichten kaum. Eine HN-Stimme: «Ich kann an null Fingern abzählen, wie oft nicht-technische QA-Leute Tests geschrieben haben.» Ein anderer Bericht beschreibt RF eingeführt, damit Product Manager Tests schreiben — niemand ausserhalb des Dev-Teams hat je Tests geschrieben.

Debugging ist schmerzhaft. HitchDev bemängelt, dass Zeilennummer und fehlgeschlagener Step nicht angezeigt werden. Die Abstraktionsschicht verschleiert Stack Traces. Standard-Breakpoint-Support fehlt — Debugging läuft über Log-Inspektion statt interaktiv, wie es bei pytest selbstverständlich ist.

Skalierung wird zur Last. Ein DZone-Migrationsbericht über 600+ Tests beschreibt: «Ohne OOP und Programmierpatterns wurde es zum Albtraum.» Keyword-Updates über hunderte Testfälle kosten unverhältnismässig. Ein Medium-Bericht ergänzt: «Keyword-Reusability sinkt bei wachsender Test Coverage, Tests werden langsamer und flaky.»

Performance-Overhead. Mehrere Vergleichsartikel berichten konsistent 30–40 % langsamer als pytest, bedingt durch Keyword-Parsing-Overhead. Ein Wechsel von SeleniumLibrary auf die Browser Library (Playwright) bringt bis zu 50 % Beschleunigung. Rigorose Benchmarks fehlen, aber die Berichte decken sich.

IDE-Support hinkt hinterher. Die VS Code Robot-Code-Extension hat 2023 weder vollständiges Auto-Formatting noch breite Autocompletion. RIDE als dedizierte IDE läuft auf macOS instabil. First-Class-IDE-Support vergleichbar mit pytest oder Playwright in PyCharm und VS Code existiert nicht.

Ökosystem-Lock-in. RF-Skills transferieren schlecht ausserhalb des Ökosystems. Stellenausschreibungen sind deutlich seltener als für pytest oder Playwright. Selbst Befürworter benennen das Hiring-Problem.

Die «versehentliche Programmiersprache» — Evolution ab RF 4.0

Die Chronologie der Programmier-Features lässt sich knapp zusammenfassen:

Version	Jahr	Neue Konstrukte
RF 4.0	2021	IF / ELSE IF / ELSE
RF 5.0	2022	TRY/EXCEPT/ELSE/FINALLY, WHILE, BREAK/CONTINUE/RETURN, Inline-IF
RF 7.0	2024	VAR-Syntax mit Scope-Kontrolle
RF 7.2	2025	GROUP (benannte Codeblöcke)
RF 7.3	2025	Variable Type Annotations (`${count: int}`)
RF 7.4	2025	Secret Variables, Typed Library Keywords

Das Resultat: getypte Variablen, Scoping, Conditionals, zwei Loop-Typen, Exception-Handling, Flow-Control, Inline-Python, Code-Gruppierung, Type-Annotations. Innerhalb von .robot-Dateien ist RF damit faktisch turing-komplett.

Kommentare aus der Community fallen entsprechend aus. HitchDev: «Ab Conditionals, Loops und Variablen — wozu dann noch eine DSL? Python ist die bessere Programmiersprache.» Der Vergleich mit C++ Templates oder MediaWiki Templates fällt im Forum öfter — als «DSL-Treadmill», bei der eine ursprünglich einfache Sprache schrittweise zur unvollständigen Programmiersprache wird. Ein RF-Forum-User: «In professioneller Nutzung ist RFs keyword-basierte Testsprache umständlich. Warum nicht Python als Sprache und RF als Support-Library?»

Pekka Klärck selbst hat die Spannung 2021 offen eingeräumt. Aus der RF-5.0-Umfrage gingen TRY/EXCEPT und WHILE als meistgewünschte Features hervor — Klärcks Kommentar: «Diese Features wären alle verfügbar, wenn sie ihre Keywords einfach in Python implementieren würden.» Das ist ein bemerkenswert offenes Eingeständnis, dass die Userbasis RF von seiner Gründungsphilosophie wegzieht.

Das Thin-Robot-Layer-Pattern

Der pragmatische Mittelweg, den erfahrene Nutzer beschreiben: RF nur auf der Testfall-Ebene. Logik, Verzweigungen, Schleifen, Datenmanipulation — alles in Python. RF wird zum reinen Runner für Routing, Variablen-Verwaltung und Logging.

Aus der Community sind dazu zwei Stimmen prominent. Robin Mackaij: «Ich schreibe Logik in Python. Für Testfälle aber ist Python eine furchtbare Wahl — da will man funktionale Schritte ausdrücken.» Bartłomiej Hirsz, RF-Contributor: «Man kann die Implementierung austauschen, ohne Testfälle zu ändern.» Beide sehen das Pattern als beabsichtigte Architektur, nicht als Kompromiss.

Kritiker sehen dasselbe Pattern anders. Wenn alle echte Arbeit in Python passiert, ist der RF-Layer Overhead ohne proportionalen Mehrwert. Der DZone-Migrationsbericht: ein Feature, das in RF rund zwei Monate gedauert hätte, wurde in pytest in einer Woche umgesetzt.

Ein Maxilect-Erfahrungsbericht liefert zwei Datenpunkte aus demselben Team. Projekt 1: alles in RF-DSL geschrieben — die Hilfs-Library wuchs auf 6’700 Zeilen RF-Code, «wurde schwer wartbar». Projekt 2: Thin-Layer-Pattern — RF wurde zum reinen Runner, «die Arbeit fühlte sich an wie normale Entwicklung». Ein Team, zwei Architekturen, klares Ergebnis.

Wo RF im Vergleich steht

Dimension	Robot Framework	pytest	Playwright	Cypress
Sweet Spot	Acceptance / ATDD, Mixed-Skill-Teams	Unit, Integration, API	Web E2E	JavaScript Web E2E
Ausführungsgeschwindigkeit	Am langsamsten (rund 30–40 % Overhead)	Am schnellsten (Python)	Schnell (Browser-Level)	Schnell (In-Browser)
Built-in Reports	Exzellente HTML-Logs	Plugins nötig	HTML + Trace Viewer	Dashboard
Non-Coder-freundlich	Ja (Keyword-Driven)	Nein	Nein	Nein
Multi-Plattform	Web, API, Mobile, Desktop	Via Libraries	Nur Web	Nur Web
Debugging	Log-basiert, limitiert	Voller Python-Debugger	Trace Viewer, Inspector	Time-Travel
Parallelisierung	Extern (Pabot)	pytest-xdist	Native Sharding	Bezahl-Feature

Migrationstrends bestätigen das Bild. Häufigste Wege weg von RF: pytest in Python-Teams, Playwright nativ in Web-Teams. Ein verbreiteter Hybrid: RF + Selenium → RF + Browser Library — also nicht weg von RF, sondern weg von Selenium. Hin zu RF kommen einzelne SpecFlow-BDD-Teams nach der SpecFlow-Einstellung. Der Marktanteil liegt laut 6sense bei rund 4.92 %, Rang 6 unter Test-Frameworks, mit Stärke in Manufacturing, Telekommunikation und Embedded.

Einordnung

Die These «RF entfernt sich von seiner ursprünglichen Intention» wird durch die Community-Diskussionen klar bestätigt. RF hat seit 2021 systematisch Programmier-Konstrukte hinzugefügt — pro Major-Release etwa eines. Der RF-Schöpfer hat die Spannung anerkannt. Forumsthreads, HN-Diskussionen, Migrationsberichte thematisieren das DSL-Treadmill-Problem konsistent. RF 2025 ist nicht mehr das tabellarische Testdatenformat von 2008.

Die Verteidigung lautet: die neuen Konstrukte sind optional, einfache Testfälle bleiben einfach. Das stimmt technisch. In der Praxis aber nutzen Teams die Features, sobald sie verfügbar sind. Die Codebasis wird komplexer, die Lernkurve länger.

Das Thin-Layer-Pattern ist die pragmatische Antwort: RF nur dort, wo es seinen ursprünglichen Vorteil ausspielt — fachliche Lesbarkeit, Multi-Tech-Orchestrierung, Audit-fähige Reports. Logik, Datenverarbeitung und Kontrollfluss in Python, wo sie hingehören. Wer RF heute neu einsetzt, sollte diesen Mittelweg von Anfang an als Standard-Architektur wählen — nicht als nachträgliche Korrektur, wenn die Suite längst zu gross für die DSL geworden ist.

Quellen

Sie evaluieren Robot Framework für ein neues Projekt oder bewerten eine bestehende RF-Suite gegen pytest? Im UTAA-Workshop ordnen wir die Architekturentscheidung projektspezifisch ein. Mehr zur Methode oder direkt anfragen.