Kompakt: die Robot Framework Online Konferenz 2020

Am 30. Juli 2020 lud die Imbus AG zur 1. Online-Konferenz rund um "Robot Framework" ein, die Rene Rohner souverän moderierte. Rene ist neben seiner Tätigkeit als Software Testing Consultant bei Imbus auch Mitglied im Vorstand der Robot Foundation, welche das Ziel hat, die Entwicklung von Robot voranzutreiben.
Zum Konferenzbeginn um 14 Uhr waren ca. 140 GotoMeeting-Slots besetzt, was angesichts 145 angemeldeter Teilnehmer ein durchaus gutes Ergebnis ist. Der erste Block bot vier Vorträge, bevor sich die Teilnehmer dann auf verschiedene virtuelle Räume verteilten, um dort in Workshops unterschiedliche Themen zu diskutieren:

Alea iacta sunt: "SKIP": Der Hauptgrund für eine Erhöhung der Major-Release-Number auf 4 ist aber sicherlich die Tatsache, dass das Konzept der "criticality" ab dieser Version nicht mehr existieren wird und durch den Status SKIP abgelöst werden wird.

Zur Erklärung: Bisher werden in Robot alle Testcases per default als critical betrachtet; sie bestimmen deshalb am Ende einer Suite den Status. Beim Aufruf von Robot kann dieses Verhalten aber verändert werden, indem mit den Schaltern --critical bzw. --noncritical die Tags der Tests als Pattern angegeben werden, die als kritisch bzw. nicht-kritisch gelten sollen. Und damit kein Missverständnis auftaucht: es wird damit nicht etwa ein "critical"-Status gesetzt, sondern lediglich genauer bestimmt, welche Tests überhaupt die Erlaubnis haben, ggf. den Gesamtstatus zu verändern.

Ob nun SKIP einen Ersatz für die Kritikalität darstellt, wurde im Robot-Slack-Channel und auf GitHub rege diskutiert. Pekka entschied genau dies und begründet das m.E. sehr ausführlich und nachvollziehbar im eigens dafür angelegten Issue #3624. Als einer der Hauptgründe nennt Pekka, dass die "criticality" immer ein "special feature" von Robot war und die Zusammenarbeit mit anderen Tools dadurch nicht gerade erleichtert wurde.

In Kürze: um zukünftig das gleiche Verhalten von --noncritical [tagpattern] zu erreichen, reicht --skiponfailure [tagpattern]. Entsprechend getaggte Tests werden ausgeführt, jedoch als "skipped" markiert, sollten sie fehlschlagen; sie haben keinen Einfluss auf das Gemsamtergebnis. Um die Migration zu erleichtern, enthält RF 4.0 Aliase für critical und noncritical, die auf das neue skiponfailure verweisen. (Ich rate allerdings dazu, solche Workarounds gar nicht erst zu benutzen. Spätestens ab Version 5 wird ein Umstieg sicher zwingend notwendig sein.)

Interessant an dieser Stelle der in Issue 3625 beschriebene Ansatz, weitere "custom Status" zu bilden:

--addstatus NON-CRITICAL:SKIP:non-critical:pink --skiponfailure non-critical
--addstatus KNOWN_ISSUE:FAIL:bug-id-*:purple

Sie sieht schon sehr befremdlich aus, die Robot-Implementierung von Kontrollstrukturen wie IF/ELSE und TRY/EXCEPT. RF Version 5.0 soll das endlich glattziehen und es auch erlauben, solche Strukturen zu verschachteln (was aktuell leider nicht erlaubt ist). Bis dieses Release erscheint, wird allerdings noch Zeit vergehen - Pekka rechnet frühestens mit Juni 2021. Ab diesem Release ist dann übrigens auch definitiv Schluss mit dem Support für Python 2.x.

Playwright erlaubt die Fernsteuerung von Chromium-, Webkit-, und Firefox-basierten Browsern über eine gemeinsame API und verspricht cross-browser und cross-OS-support. Es ist also möglich, z.B. mit einer Safari-Instanz auf Windows zu testen.

Weiterhin wurde das API modernisiert, sodass ein click auf ein Element implizit vorher auf das Erscheinen des Elements wartet.
Playwright kann außerdem mit Webcomponents umgehen, d.h. in sich geschlossene DOM-Bäume innerhalb eines anderen DOMs erkennen und ansprechen. Killerfeature in meinen Augen: die Selector engine erlaubt die gemischte Verwendung von Text-, CSS- und XPath-Selektoren - und das in einer Zeile:

# find span css selector inside xpath selector:  xpath=//html/body/div >> css=span 

Anstatt vollwertige Instanzen von Browsern zu starten, kann Playwright sog. Contexte innerhalb des Browsers erstellen. Es ist damit also möglich, mehrere Tabs in einem Browserfenster zu öffnen, die jeweils z.B. unterschiedliche Geolocation- oder Sprach-Settings in ihrem Context haben. Das ist deutlich komfortabler und schneller, als dies einzelnen Browser-Instanzen als Kommandozeilenargument mitzugeben.

Playwright kann Tastatur- und Maus-Events nativ absetzen. Warum das wichtig ist? Auf manchen Webseiten kann es passieren, dass das bloße Setzen von Werten in einem Formular nicht funktioniert, die Anwendung also nicht darauf reagiert. Die Eingabe "von Hand" hingegen funktioniert, weil hierbei Tastatur-Aktivität im Spiel ist. 

Unter der Federführung von Mikko entstand nun die "Robot Framework Browser Library", welche auf Playwright aufsetzt. Mikka ist kein unbeschriebenes Blatt, sondern war vier Jahre Mitglied des Robot Core Developer Teams und wirkte an der Entwicklung des RIDE-Editors für Robot mit. Die Robot-Library "Pabot" zur parallelen Ausführung von Robot-Tests stammt ebenfalls von ihm. 

Dann übernahm der Moderator selbst das Steuer und zeigte den Teilnehmern die verschiedenen Möglichkeiten, Robot Framework zu debuggen. Dabei ging er quasi "von außen nach innen" vor, zeigte nämlich zunächst die Verwendung der DebugLibrary, die mit dem Keyword Debug den einen Robot-Test einfach anhält. Auf der Kommandozeile kann dann interaktiv debugged werden. Wer ipython kennt bzw. mit ipdb debugged, ist hier sofort heimisch.

Weil das nicht genug für Rene war, programmierte er vor einiger Zeit seine eigene Debugger-Library - und die kann sich sehen lassen.

Anders als die DebugLibrary wartet die Debugger-Library nicht auf ein Keyword für den Einstiegspunkt, sondern sucht diesen selbst - nämlich, sobald ein Keyword fehlschlägt (welchen besseren Zeitpunkt zum Debuggen gibt es wohl...? 🙂 ). Wichtig ist nur, die Library als "Listener" zu starten, d.h. direkt beim Aufruf von Robot:

robot --listener Debugger path/to/test.robot 

Debuggen im Editor: Obwohl ich bekennender Fan von VS Studio Code bin, hatte es mir bisher der RED-Editor angetan. Rene zeigte aber, dass der Robot Framework Language Server aber mindestens die gleichen Möglichkeiten für Code-Completion und Debugging bietet. Werde ich mir definitiv nochmal ansehen. Spätestens mit den Debug-Möglichkeiten des RFLS kann man dann so richtig im Code wühlen und beim Debuggen bis in den Python-Code von Robot selbst hinabsteigen. Manchmal ist gerade das extrem hilfreich, um zu sehen, mit welchen Daten Robot eigentlich arbeitet.

All diese Debug-Möglichkeiten demonstrierte Rene live und sehr anschaulich. Da war sicher für jeden noch was dabei.

Es lohnt sich definitiv, solche Online-Events weiter im Auge zu behalten. Es geht natürlich z.B. nichts über eine Robocon in Helsinki (und finnisches Bier) - aber besondere Zeiten erfordern besondere Maßnahmen, und die hat Imbus sehr gut gewählt. Die Konferenz funktionierte unter GotoMeeting auch mit annähernd 150 Teilnehmern ruckelfrei. 

Schön, dass Pekka Klärck das Event mit seinem Vortrag zur Roadmap bereichert und damit auch quasi "höchst offiziell" gemacht hat. Der Vortrag von Nils kam mir gerade recht, weil ich meine CheckMK-Monitoring-Erweiterung "RobotMK" auch mit der Möglichkeit ausstatten möchte, Robot-Tests in Kubernetes zu triggern.

Besonders hängen geblieben sind bei mir die Vortrgäge von Mikko und Christoph über die neue Browser Library für das Playwright-Framework. Ich bin überzeugt, dass Playwright auf lange Sicht die Web-Test-Methode Nr. 1 bei Robot werden wird, auch wenn die Browserversionen (anscheinend?) nicht vorgewählt werden können und man an die mitgelieferten Browser gebunden ist, also keinen im OS installierten Browser verwenden kann. 

Und jetzt werfe ich doch gleich mal VS Studio Code an und nehme den Robot Framework Language Server unter die Lupe...