Nach Arbeiten in einem großen Projekt (~ 200-Web-Entwickler) mit Robot Framework (RF) für ca. 3 Monate, halte ich den Begriff „Framework“ in „RobotFramework“ für ein wenig irreführend. Das Robot-Framework ist mehr als ein Framework (mehr als ein Rahmen), es ist auch eine eigene Programmiersprache.
In diesem Artikel will ich nicht Robot-Framework als Testautomatisierungs-Sprache schlecht machen, obwohl sich die Syntax ein wenig seltsam anfühlt. Ich möchte lediglich zeigen, dass Robot-Framework eine Programmiersprache ist und einige Schlussfolgerungen ziehen.
Robot-Framework hat eine eigene Syntax
Robot-Framework hat Variablen (mit unterschiedlichem Scope)
Sie erstellen diese wie folgt:
${hi} = Set Variable Hello, world!
${hi} = Set Test Variable Hello, world!
${hi} = Set Suite Variable Hello, world!
${hi} = Set Global Variable Hello, world!BuiltIn-Bibliothek-Dokumentation
Robot-Framework hat Funktionen
In Robot-Framework werden Funktionen Schlüsselwörter (keywords) genannt.
Sie erstellen diese wie folgt:
Return One Value [Arguments] ${arg}
Do Something ${arg}
${value} = Get Some Value
[Return] ${value}
Robot-Framework hat bedingte Anweisungen
Dies sieht wie folgt aus:
${result} = Run Keyword If ${rc} == 0 Zero return value
... ELSE If 0 < ${rc} < 42 Normal return value
... ELSE If ${rc} < 0 Negative return value ${rc} arg2
... ELSE Abnormal return value ${rc}
BuiltIn-Bibliothek-Dokumentation
Robot-Framework hat Schleifen
Und sie sehen wie folgt aus:
Run my hobbies
:FOR ${index} IN RANGE 1 11
\ Watch TV
\ Plague your neighbor
\ Play with your dog
Robot-Framework hat seine eigene IDE
Es heißt „RIDE“ und es hat seine eigenen Tücken.
Robot-Framework hat seine eigenen Bibliotheken
Schauen Sie beispielsweise in die Selenium2Library. Sie werden sehen, dass die Nomenklatur nichts mit der von der WebDriver-API gemeinsam hat.
… und Robot-Framework hat seine eigenen Fallstricke und Bugs
Da der Testcase-Timeout einen Fehler im der Reporting-Engine erzeugt, musste ich einen eigenen customized Timeout implementieren … loop… sleep… boilerplate…
Zusammenfassung und Fazit
- Testautomatisierung ist Programmierung. Robot-Framework ist eine Programmiersprache. Und Sie benötigen Zeit diese zu lernen.
- Ich habe keine Vorteile gegenüber Java/TestNG gefunden (auch nicht nach 3 Monate arbeiten in Vollzeit mit RF).
- Denken Sie an die Java-Web-Entwickler in Ihrem Projekt/Scrum-Team. Wollen diese das Lesen und Pflegen der Testskripten in einer unbekannten Programmiersprache?
- Die Skill-Kombination von Robot-Framework und Browser-Automatisierung ist selten. In XING finden Sie die Skill-Kombination „Selenium UND Robot Framework“ bei gerade mal 12 Personen. Aber die Skill-Kombination „Selenium UND Java“ finden Sie bei mehr als 1000 Personen.
- Denken Sie an Ihr Projekt Staffing: Es ist einfacher, ein Profi mit Java-Fähigkeiten zu finden als einen mit Robot Framework Fähigkeiten.
- Denken Sie auch an die Größe der Community für Support, Entwicklung der Tools, Artikel…
Mein Fazit: Wenn Sie ein Abenteurer sind, versuchen Sie es mit Robot-Framework.
Ich kann diesem Artikel so nicht zustimmen. Ich finde die Betrachtung sehr einseitig, gerade im Zusammenhang mit Selenium. Hier meine Vorteile von Robot Framework (RF):
– TestNG hat, im Vergleich zu RF, schlechte Reports. Man bekommt in Robot Framework automatisch für jeden Testschritt einen Report mit Eingangs- und Ausgangsgrößen. Screenshots sind ebenfalls Einzeiler und werden bei einem Fehler im Browser sogar automatisch erzeugt.
– Es gibt für RF mit „Data Driver“ eine Integration von Data Driven Testing.
– Man muss sich in Robot Framework nicht um die Erstellung von Objekten kümmern. Ein einfaches „Open Browser“ genügt. Man muss nicht immer alle driver Variablen von einer Funktion zur Nächsten tragen.
– RF basiert auf Python und es ist sehr einfach möglich mit Python Funktionen die Funktionalität zu erweitern.
– Man kann mit RF Abnahmetests gut beschreiben. Die Keywords wirken teilweise fast wie richtige Anweisungen. Das sollte es auch Laien ermöglichen Tests zu schreiben. Klar, die Low-Level Schritte müssen zuerst von technisch versierten Leuten erstellt werden. Aber die eigentlichen Workflows können dann von fachlichen Testern erstellt werden. Das ist in Java viel komplizierter.
TestNG ist eigentlich ein Unittest Framework und das merkt man eben vor allem beim Reporting.
Hallo Alexander, besten Dank für deinen Hinweis. Ich kenne das Robot Framework nur vom „drüber lesen“ und kann nicht viel dazu sagen. Ich habe aber auch schon sehr viel gutes vom Robot Framework gehört, das kann ich wohl bestätigen.
Der Artikel ist auch schon etwas älter und von einen damaligen Gastautor. Wahrscheinlich macht auch Sinn, dass wir hier mal einen neuen Robot Framework Artikel in eine ausführliche Art Tutorial beschreiben. Leider fehlt gerade Zeit und auch die Robot Framework Kompetenz.
Falls du (oder jemand anders der sich Kompetent genug erachtet), einen Gastartikel bei uns über das Robot Framework eröffnen möchte, um es mal ausführlich und komplett zu erklären, dann melde dich gerne. Email unter Kontakt.
Ansonsten, falls jemand eine andere Meinung zum Robot Framework hat, lasst Sie gerne hören.
In der Tat, der Artikel scheint von 2014 zu sein. Mittlerweile ist Robot Framework etabliert – trotz kaum veränderter Syntax.
Warum ist das so: Hier wird immer der Vergleich zu TestNG gezogen. TestNG (oder vergleichbare aktuelle Technologien) ist für Java Entwickler. Der Testfall wird von einem Java Entwickler geschrieben – und kann nur von einem Java Entwickler ausgewertet werden. Das ist für die aller meisten Testfälle in Ordnung. Bei sehr fachlichen Tests ist das aber ein Problem, den hier liegt das Know How über User Scenarios eher beim Business Analysten – und der ist oft kein Java Entwickler.
Robot Framework abstrahiert die Programmiersprache (Python) weg. Man muss nicht programmieren können, um mit Robot zu automatisieren. Man *kann* mit Robot programmieren, sollte das aber unbedingt vermeiden! Wenn der Robot Testfall nicht menschenlesbar ist, mit Variablenzuweisungen nur so um sich wirft, dann läuft was falsch. Die „komische“ Syntax ist für Nicht-Entwickler (was Tester anfangs oft sind) ein willkommenes Entgegenkommen und macht, bei richtigem Sprachgefühl, die Testfälle leicht verständlich.
Warum findet man keine Kombination von Robot+Selenium auf Xing (bzw. heute noch aktiven Plattformen)? Weil Selenium unbemerkt unter Robot mit läuft. Ob man in den Robot Testfällen Playwright oder Selenium verwendet, merkt man kaum. Die Dependencies werden installiert und dann läuft es einfach. Man muss nicht wissen wie Selenium oder Playwright funktionieren. Ich würde nicht auf die Idee kommen Robot+Selenium in mein Profil zu schreiben. Robot+WebUI vielleicht eher. Aber das ist im Grunde so als würde ich „Java + Garbage Collection“ in mein Profil schreiben. Als Java Entwickler nutze ich Garbage Collection – aber explizit in mein Profil aufnehmen würde ich es nicht. Es läuft halt so mit. So ist das Robot und Selenium auch.
Ich lasse mal ein paar aktuelle Links hier:
Hauptseite von RF: https://robotframework.org
Seite von Robocorp (Prozessaautomatisierung mit RF): https://robocorp.com
Und ganz wichtig: RIDE als IDE gibt es immer noch. Sie hat den einmaligen Vorteil, dass man sie einfach als Python Modul installieren kann. Ansonsten gibt es mittlerweile das Robot Framework Language Server Plugin für IntelliJ/PyCharm und VSCode. Für VSCode sogar das RobotCode Plugin. Mächte Plugins mit Autocompletion, drill-down Funktion bis rein in den Python Code, Debugger etc. etc.