Automatisierte Tests mit dem Robot-Framework
Testautomatisierung findet oft nur bis zur Klassen- und/oder Entwicklerebene statt. Besser ist es jedoch, wenn man zusätzlich das Zusammenspiel der Komponenten inklusive GUI testet. Robot ist ein Framework für verständliche, systemübergreifende Tests.
- Roger Butenuth
Testautomatisierung findet oft nur bis zur Klassen-/Entwicklerebene statt. Besser ist es jedoch, wenn man zusätzlich das Zusammenspiel der Komponenten inklusive GUI testet. Robot ist ein Framework für verständliche, systemübergreifende Tests.
Für das Testen ist es heute egal, ob man in Java oder COBOL entwickelt, für nahezu alle Sprachen existieren Unit-Test-Bibliotheken. Entwickler haben daher keine Ausrede, wenn sie den Code nicht automatisiert prüfen. Der Name ist allerdings Programm: Unit-Tests eignen sich gut dazu, einzelne Klassen oder Methoden auf Korrektheit zu überprüfen. Melden die Testfälle einen Fehler, sollte sich dieser – bei gutem Design – nur in einem kleinen, überschaubaren Stück Code befinden. Leider reicht das in der Praxis für größere Systeme nicht aus: Viele Fehler entstehen erst dadurch, dass (kleine) Teile nicht so zusammenspielen, wie es sich ihre Entwickler vorgestellt haben. Je nach Projektgröße benötigt man neben den Unit-Tests daher noch eine oder mehrere zusätzliche Testebenen: etwa Tests größerer Komponenten, die sich aus kleineren zusammensetzen, Tests mit Nachbarsystemen und Tests mit GUI.
Tests für technische Schnittstellen können Entwickler noch unter sich klären, auch wenn sie in verschiedenen Teilprojekten arbeiten. Auf GUI-Ebene sollte oder möchte der Fachbereich dagegen meist mitreden. Unit-Tests in Programmform sind dafür als Diskussionsgrundlage denkbar schlecht geeignet. Word-Dateien mit Testdrehbüchern lassen sich andererseits nicht automatisch ausführen, sie benötigen einen (teuren) menschlichen "Interpreter". Tests nach jedem Build sind mit dieser Technik nicht praktikabel.
Türöffner für unterschiedliche Seiten
Das "Keyword Driven Testing" bietet eine Lösung für das beschriebene Problem: Es nutzt eine Notation, die für Menschen ohne tiefe IT-Kenntnisse lesbar ist, sich aber auch automatisch ausführen lässt. Ein Test für einen Taschenrechner könnte damit folgendermaßen aussehen:
| Gebe Zahl ein | 90 | |
| DrĂĽcke Taste | sin | |
| Erwarte Ergebnis | 1 | mit Abweichung 0,0001 |
Die Tests werden in Tabellen gespeichert, eine Zeile beginnt immer mit einem Schlüsselwort, gefolgt von Parametern. Was kann ein Testframework mit Keywords wie "Drücke Taste" anfangen – ohne Zusatzinformationen nichts. Es werden Adapter für das zu testende System benötigt. Das Framework ist damit – wie JUnit – nur noch für die Ausführung und das Reporting zuständig. Oft liefert der Anbieter generische Adapter mit, sodass man beispielsweise Web- oder Swing-Java-Anwendungen leicht anbinden kann, ohne sich um die Low-Level-Technik zu kümmern.
Fitnesse und Robot setzen beide auf Keyword Driven Testing. Im vorliegenden Artikel wird Robot, das neuere der beiden, genauer beschrieben. Dessen Idee stammt aus der Master-Arbeit von Pekka Laukkanen [1], die Open-Source-Implementierung in Python von Nokia Siemens Networks. Robot ist unter der Apache License 2.0 verfügbar. Auf der Projekt-Website finden sich neben den obligatorischen Download-Optionen eine ausführliche Dokumentation und Verweise auf extern verfügbare Keyword-Bibliotheken, zum Beispiel für den Zugriff auf Browser, Swing und Datenbanken. Eingebaute Bibliotheken ermöglichen Manipulationen von String- und Listenvariablen. Zusätzlich gibt es Assert-Keywords ähnlich den Assert-Methoden in JUnit sowie Schlüsselwörter für Zugriffe auf das Betriebssystem (Datei-Handling, Starten externer Programme). Später wird anhand eines Beispiels gezeigt, wie sich Robot mit eigenen Bibliotheken erweitern lässt.
RIDE – die Robot-IDE
Zum Programmieren nutzt man meist keinen einfachen Editor mehr, sondern eine integrierte Entwicklungsumgebung (IDE). Auch beim Testen mit Robot wird dieser Komfort durch die Robot-IDE RIDE geboten. Sie ist ebenfalls in Python implementiert und damit betriebssystemunabhängig verfügbar. Gegenüber Java-IDEs ist die Komplexität deutlich geringer, was sie für IT-affine Fachbereichsmitarbeiter handhabbar macht.
In Abbildung 1 sieht man den vorgestellten Taschenrechner-Testfall in RIDE. Links im Explorer fallen neben dem Testfall einige andere Einträge auf. Es handelt sich um selbst definierte Keywords. Für das Beispiel wird so die Anbindung an einen echten Taschenrechner simuliert. In der Praxis lassen sich selbst definierte Keywords nutzen, um generische, Low-Level-Schlüsselwörter zu kapseln. Statt "Input Text numberEntryId 90" kann man sprechender "Gebe zahl ein 90" schreiben. Das Keyword gibt den Parameter weiter: "Input Text numberEntryId ${Zahl}".
Wie beim Programmieren ersetzt RIDE fundierte Kenntnisse der Syntax. Das Speicherformat der Tests ist einstellbar, Robot bietet verschiedene Optionen an: speziell formatierte Text- und CSV-Dateien oder HTML. RIDE ergänzt HTML-Dateien mit CSS, sodass sich eine übersichtliche Darstellung ergibt. Die IDE enthält einen Test-Runner und stellt die Testergebnisse formatiert dar (Reiter "Run").