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.