Lieferung 8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests

Transkript

1 Lieferung 8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket AP 8 Test- und Qualitätssicherungsumgebung Arbeitspaketleitung Andrena Förderkennzeichen 01IS11012A-C Projektleitung andrena objects AG Jochen Winzen Partner andrena objects ag arconsis IT-Solutions GmbH FZI Forschungszentrum Informatik Autoren Christian Jansohn, Martin Küster Lieferdatum M21 Letztes Änderungsdatum Version 1.0 ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 1

2 1 Einleitung Dieses Dokument beschreibt die Erkenntnisse und den aktuellen Stand der Entwicklung im ModAgile Mobile Projekt. Den Fokus dieses Dokuments stellt der Bericht des aktuellen Entwicklungsstands im Bereich der Qualitätssicherung dar. Zwei zentrale Elemente sind dabei die domänenspezifischen Sprachen (Domain Specific Language DSL) für Unit-Tests und Oberflächen-Tests (UI-Tests) sowie die dafür erstellten textuellen Modelleditoren. In agilen Software-Entwicklungsprozessen ist die kontinuierliche Entwicklung von Tests nach dem Test- First-Ansatz ein elementarer Bestandteil. Die modellgetriebene Entwicklung von mobilen Anwendungen für unterschiedliche Zielsysteme stellt für das Testen eine erhebliche Herausforderung dar. Relativ kleine Änderungen am Anwendungs-Modell erzeugen in den Generaten für die verschiedenen Zielarchitekturen potenziell große Mengen an generiertem Code. Ein naiver Ansatz der manuellen Entwicklung von Tests für den generierten Code würde einen unverhältnismäßigen Mehraufwand erzeugen. Ebenfalls ist es wenig sinnvoll Programme auf einer Zielplattform unabhängige Ebene zu definieren und modellieren und die dazugehörigen Tests auf tieferer Ebene entwickeln zu müssen. Die logische Schlussfolgerung ist die Spezifikation von automatischen Tests auf gleicher Abstraktionsebene wie dem Anwendungs-Modell. Testen auf Modell-Ebene Das Testen auf Modell-Ebene dient der plattformunabhängigen Validierung des Modells. Dabei sollen Fehler im Modell selbst gefunden werden. Hierzu werden der Test und das zu testende Modell in einer eigenen auf das Meta-Modell zugeschnittenen virtuellen Mock-Umgebung ausgeführt. Testen von plattformspezifischen Generaten Aus den Test-Spezifikationen in der Test-DSL lassen sich durch entsprechende Transformationen plattformspezifische Tests für jede der Zielarchitekturen erstellen. Die generierten Tests verwenden Programmiersprache und Programmbibliotheken der jeweiligen Zielarchitektur und testen den generierten Programmcode für die entsprechende Zielarchitektur. Hierdurch können plattformspezifische Probleme und Fehler von Transformatoren frühzeitig erkannt werden. 2 Unit- und Akzeptanztestsprache Unit-Tests sind in der Software-Entwicklung das Standardmittel, um die korrekte Funktion von einzelnen Softwarekomponenten in der Regel einzelne Klassen und Methoden isoliert vom Rest des Systems sicherzustellen. Das Grundverfahren beim Unit-Testen ist das Aufrufen der zu testenden Methoden mit vom Entwickler definierten Parametern. Nach dem Aufruf wird das Ergebnis mit dem erwarteten Ergebnis verglichen. Kommt es hierbei zu Abweichungen, wurde ein Programmierfehler entdeckt. Bei der gewöhnlichen plattformspezifischen Entwicklung werden Unit-Tests in der Regel technisch durch ein Stück Software realisiert, welche in der gleichen Programmiersprache wie der zu testende Programmcode geschrieben wurde. Unterstützt wird das Schreiben von Programm-Code durch plattformspezifische Test-Frameworks. Diese erleichtern das Initialisieren von Testdaten sowie das Organisieren und strukturieren von Tests sowie das Erzeugen von Übersichtlichen Ausgaben von Test- Ergebnissen. ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 2

3 Im Modagile-Entwicklungsprozess ist vorgesehen, dass bestimmte Programmteile wie die anwendungsspezifische Logik vom Entwickler selbst für alle Zielplattformen entwickelt werden soll. Beim Entwurf des Domänenmodells hat der Entwickler die Möglichkeit Methoden zu deklarieren, welche die Schnittstelle zu anwendungsspezifischer Logik darstellen. Während des Transfomationsprozesses,werden aus dem plattformunabhängigen Domänenmodell plattformspezifische Generate erzeugt. Im Generat werden für alle deklarierten Methoden leere Methodenrümpfe erzeugt, welche vom Entwickler mit passendem Programmcode gefüllt werden. Es ist wünschenswert, die Qualität dieses Codes durch Unit-Tests sicherzustellen. Eine Möglichkeit hierfür wäre, für jede Implementierung einen Unit-Test von Hand zu schreiben und dabei die etablierten Frameworks der Zielplattformen zu definieren. Der hier entstehende Nachteil ist, dass die gleichen Testszenarien von Hand für jede gewünschte Zielplattform zu entwickeln. Das bringt einerseits zusätzlichen Aufwand bei der Entwicklung und birgt andererseits auch noch das Risiko, dass sich die Testszenarien unterscheiden und somit ein gleiches Verhalten der Anwendungslogik auf verschiedenen Plattformen nicht mehr sichergestellt ist. Für Modagile wurde eine Unit-Test-DSL entwickelt, welche das plattformunabhängige Entwickeln von Tests ermöglicht. Die Test-DSL ist eine Sprache, welche einen speziell für Unit-Tests zugeschnittenen Befehlssatz bereitstellt. Dabei werden folgende Aspekte von Unit-Tests berücksichtigt: Strukturierung von Testdaten: Eine Test-Datei kann eine beliebige Menge von Tests enthalten. Dabei ist jeder Test durch einen Block mit eindeutigem Namen definiert. Initialisieren von Daten: Es können Instanzen von Domänenobjekten erzeugt und initialisiert werden. Methodenaufrufe: Die zu testenden Methoden können aufgerufen werden. Überprüfung von Ergebnissen: Assertion-Ausdrücke ermöglichen das spezifizieren erwarteter Daten 2.1 Stand der Entwicklung Es wurde eine Modagile-spezifische Test-DSL entwickelt, welche alle wesentlichen Aspekte eines Unit- Tests ausdrücken kann. Dazu wurde ein Xtext-basierter Parser entwickelt, welcher die entwickelten Test- Dateien verarbeiten kann. Darauf aufbauend wurde ein Transformationswerkzeug entwickelt, welcher auf dem JUnit-Framework basierende Tests erzeugen kann. 2.2 Fazit Unit-Tests sind ein wichtiges Mittel, um die Qualität von Programmcode sicherzustellen. Dies gilt auch für die modellgetriebene Multi-Plattform-Entwicklung. Durch die Verwendung einer plattformunabhängigen Unit-Test-DSL wird die Effizienz bei der Entwickelung und Wartung von Tests reduziert. 3 Generatoren Unit-Sprache Die mit Hilfe der Test-DSL spezifizierten Unit-Tests können durch Transformation in plattformspezifischen Test-Code übersetzt werden. Der generierte Test-Code basiert auf gängigen plattformspezifischen Test- Frameworks(zum Beispiel JUnit für Java). So können für das Ausführen der Tests gewohnte Werkzeuge verwendet werden(zum Beispiel der integrierte JUnit-Runner der Eclipse-IDE für Java). Bei der ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 3

4 Transformation wird die Struktur der Tests also die Namen von Dateien und Benennung einzelner Tests beibehalten. So können die komfortablen Ausgaben der plattformspezifischen Test-Werkzeuge problemlos genutzt und vom Entwickler interpretiert werden. Abbildung 1 Klassendiagramm eines simplen Domänen-Models Abbildung 1 zeigt das Klassendiagramm eines einfachen Domänen-Models, für welches in diesem Abschnitt ein Test mit Hilfe der vorgestellten Test-DSL erstellt werden soll. Die Modellierung beinhaltet zwei Klassen. Die Person besitzt die Attribute name und age. PersonList ist eine Aggregation von Personen. Die Klasse stellt eine Methode averageage zur Berechnung des Durchschnittsalters aller Personen der Liste bereit. Deren korrekte Funktion soll durch einen Test sichergestellt werden. package "de.modagile.personexample" import "classpath://de.modagile.personexample.personmodel" testcase PersonListTest { } test berechnetdurchschnittsalter ( ) { } // Initialisiere eine PersonList mit zwei Personen var personlist = new PersonList(persons => { }) new Person(name => "Klaus", age => 23), new Person(name =>"Angelika", age => 34) // Prüfe, dass averageage das richtige Ergebnis liefert assertequals(28.5, personlist.averageage()) Listing 1 Test-Quellcode ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 4

5 Listing 1 zeigt den Quellcode des Tests. Der Quellcode beginnt mit einer Package-Deklaration. Darauf folgt die Importanweisung für das in Abbildung 1 gezeigte Domänenmodell. Dies ist notwendig um die zu testenden Klassen verfügbar zu machen. Auf das Schlüsselwort testcase folgt der Name der Testsuite. Die geschweiften Klammern beinhalten alle Tests. Im vorgestellten Beispiel ist dies der Test berechnedurchschnittsalter. Dieser enthält zwei Anweisungen: 1. Die Deklaration der Variable personlist, welche eine neu zu erzeugende PersonList zugewiesen bekommt. Die enthaltenden Personen werden im Konstruktoraufruf direkt übergeben. In diesem Fall sind das Klaus(Alter 23) und Angelika(Alter 34). 2. Ein Aufruf der Prüffunktion assertequals. Diese erhält als ersten Parameter das erwartete Durschnittsalter(28.5). Der zweite Parameter ist der durch einen Aufruf der zu testenden Methode averageage tatsächlich berechnete Wert. Aus dem vorgestellten ModAgile-Unit-Test PersonListTest können mit Hilfe der ModAgile-Tools ausführbare Unit-Tests generiert werden. Abbildung 2 zeigt einen Screenshot des Java-Test-Werkzeugs JUnit bei der Ausführung des von ModAgile generierten JUnit-Tests. Man sieht, dass Bezeichner wie Paketnamen, Testcase-Namen und Testnamen übernommen wurden, so dass sich der Entwickler in den generierten Tests problemlos zurechtfindet. Abbildung 2 JUnit in Eclipse 4 Generatoren UI-Test-Sprache Für die zwei Plattformen android und ios wurden Generatoren entwickelt, die das plattformunabhängige Akzeptanztest-Modell in die jeweilige Zielplattform übersetzt. Zunächst musste der Stand der Technik für ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 5

6 das Testen auf Akzeptanz- bzw. Abnahmeebene gefunden werden. Zur Entwicklung der Referenztests wurden die Frameworks Robotium 1 für die Android-Version und die seit ios4 integrierte Automation in XCodes Instruments 2 verwendet. Beide simulieren Endbenutzer-Aktionen, wie beispielsweise das Klicken oder die Texteingabe. Bei beiden kann beim Testlauf mitverfolgt werden, wie die im Test festgehaltenen Benutzer-Aktionen auf dem Bildschirm ausgeführt werden. Daraus ergaben sich zwei Zielsprachen bzw. Frameworks, gegen die generiert werden muss: JavaScript für die Entwicklung von ios-tests unter Instruments Java für die Entwicklung von android-tests mit Robotium. Abbildung 3 Schema der Generierung für drei Plattformen (aus [1]) Das Prinzip der Generierung für verschiedene Plattformen ist in Abbildung 3 verdeutlicht. Für jede Plattform muss eine Menge von Schablonen (engl. templates) erstellt werden, die die Modell-zu-Text- Transformation ausführt, d.h. aus dem Anwendungs- und Testmodell (mit Modell 1 und Modell 2 bezeichnet) wird direkt ausführbarer Quellcode generiert. Dieser wird auf der jeweiligen Plattform mit den entsprechenden Test-Werkzeugen zur Ausführung gebracht. In beiden Plattformen war es das Ziel, den üblicherweise handgeschrieben Test-Code so gut wie möglich aus dem plattformunabhängigen Modell zu erzeugen. Spezifika der jeweiligen Plattform mussten daher in die Generatoren verlagert werden, um das Test-Modell nicht übermäßig kompliziert werden zu lassen. Das Test-Metamodell umfasst daher insbesondere die Funktionalitäten, die sich gut auf beide Plattformen abbilden lassen. Eigenschaften, die nur in einer der unterstützen Plattformen existieren, wurden zunächst zurückgestellt. Hier sind üblicherweise handgeschriebene Erweiterungen des generierten Test-Codes vonnöten, die aber in diesem Dokument nicht dargestellt sind Introduction/Introduction.html#//apple_ref/doc/uid/TP ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 6

7 4.1 Template-Strukturen Architekturell gliedert sich die Generierung in drei Bereiche. Der plattformunabhängige UILanguageGenerator ist für Aufgaben wie das Laden der beteiligten Modelle verantwortlich. Er setzt die Generierung in Gang, in dem er den jeweiligen Plattformgenerator anstößt. Von allen Generatoren werden gemeinsame Bibliotheksfunktionen genutzt, die in den CommonHelperMethods implementiert sind. Abbildung 4 Generatoren im Überblick Die gesamte Logik der plattformspezifischen Generierung liegt also in den Generatoren, die durch die bereits angesprochenen Templates realisiert sind. Das Paradigma für die Struktur der Pakete und Templates ist hauptsächlich in Lieferung 7.1 Plattformspezifische Generatortemplates für Code-Gerüst, Test, Konfiguration der Qualitätswerkzeuge beschrieben. Zusammengefasst: Pro Typ der generierten Klasse gibt es ein eigenes Xtend-Template. Diese sind gemäß ihren inhaltlichen Bezügen zu Paketen zusammengefasst, die einzelne Belange der Generierung umfassen. Da für die Testgenerierung nur ein Zielklassentyp notwendig ist, genügt es, die Information in einer Template-Datei zusammenzuführen. Die Abbildung 5 zeigt, wie die Templates mit der UI-Test-Sprache verwoben sind. Als Teil eines großen Projekts, das die UI-Test-Sprache und ihre Generatoren umfasst, ist ein Xtext-Projekt entstanden. Hervorgehoben sind die Elemente, die speziell für die Generierung notwendig sind. Oben sieht man die Templates und der Workflow, der ausgeführt wird, um plattformspezifische Tests zu generieren. Unten ist der Ordner hervorgehoben, der die von Xtend generierten Java-Quelldateien enthält. Semantisch sind diese äquivalent zu den Templates. Jedoch ist ihre Ausführung viel performanter als eine Ausführung der Templates mit einem interpretierenden Ansatz (wie früher bei Xpand). Die Konfiguration des Editors, der aus der Sprachdefinition generiert wurde, erlaubt es, Generatoren einzuhängen, die aufgerufen werden, sobald die UI-Test-Datei gespeichert wird. Im Hintergrund läuft dann der Prozess der Generierung für die unterstützten Plattformen los. Zunächst wird der UI-Test-Code in ein Modell übersetzt. Dieses Modell wird in den Templates zur Generierung traversiert und schreibt an die eingestellten Stellen im Dateisystem die Testklassen und Testmethoden. ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 7

8 Abbildung 5 Struktur von Test-UI-Sprache und Generatortemplates 4.2 Generierung für android Zunächst soll ein Beispiel zeigen, was das Ziel der Generierung unter android ist. Dazu ist in Abbildung 6 ein Referenztest abgebildet, der die Anwendung Mamex testet. Es wird zunächst eine Person angelegt, danach ihr Geburtsdatum gesetzt und gespeichert. Die Zusicherung prüft, ob die Person in der Liste angezeigt wird. ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 8

9 Abbildung 6 Referenztest unter android (aus [1]) Für die Templates ist das plattformunabhängige Test-Modell nötig. Der textuelle Editor für diese Testsprache wurde bereits im Detail in Lieferung 6.3 Textuelle Editoren für alle identifizierten Sichten beschrieben, daher wird an dieser Stelle nur darauf verwiesen. Im Kern wird die Ausführungslogik des Tests sowie die Zusicherung am Ende in der in Abbildung 7 dargestellten Form als Eingabe verwendet. Abbildung 7 Plattformunabhängiger Test-Code (aus [1]) Die android-spezifischen Templates bauen daraus Quellcode, der in möglichst großem Umfang der handgeschriebenen Referenz aus Abbildung 6 entspricht. Das Ergebnis der Generierung ist in Abbildung 8 abgebildet. ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 9

10 Abbildung 8 Generat des UI-Tests unter Robotium/android (aus [1]) In dem illustrierten Fall ist wegen der Einfachheit des Tests das Generat mit der Referenz bis auf die Kommentare sogar identisch. Normalerweise werden aber Konstrukte enthalten sein, die schwerer lesbar sind, weil sie generiert sind. Über dies kann sich der Tester jedoch hinweg setzen, weil der vollständig ausführbare Code lediglich zur Ausführung gebracht werden muss. Die Spezifikation des Testfalls findet schließlich nur noch in der plattformunabhängigen Variante statt. 4.3 Generierung für ios Ähnlich wie für den android-fall startet man mit einer Spezifikation des Tests in der plattformunabhängigen Sprache (Abbildung 7). Das Ziel der Generierung unterscheidet sich jedoch deutlich von der Java-basierten Variante mit Robotium. In ios werden Anwendungen mit dem Appleeigenen Werkzeug Instruments getestet. Dieser benutzt JavaScript, um das Verhalten, das auf dem Simulator ausgeführt werden soll, zu beschreiben. Auch für ios wird zunächst ein Referenztest, geschrieben von Hand, gezeigt. Danach bietet das Generat, das von dem entwickelten UI-Test-Generator herauskommt, die Möglichkeit zum Vergleich mit der Referenz. Abbildung 9 Referenztest unter ios ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 10

11 Abbildung 9 zeigt den Test, wie man ihn von Hand in JavaScript schreiben würde, Abbildung 10 zeigt das Generat. Abbildung 10 Generierter ios-test in JavaScript Wieder ist die Ähnlichkeit hoch. Allerdings gibt es diesmal einen kleinen Unterschied. Dadurch, dass die Buttons in Android und in ios nicht immer einen Namen haben, müssen sie im Generat über ihren Index gefunden werden und können danach gedrückt werden (Zeile 8). Da der Imagebutton mit dem Label x office calendar unter Android keinen Namen hat, wird er einfach über seine Ordnungsnummer (0) im Bereich der Zellen gefunden und gedrückt. Der Umfang der gesamten Sprache kann hier nicht in Gänze erläutert werden. Für eine Übersicht der Features der UI-Test-Sprache verweisen wir daher auf die Lieferung 6.3 Textuelle Editoren für alle identifizierten Sichten, in der das Metamodell sowie die konkrete textuelle Syntax der Sprache erläutert sind. 5 Schluss Es wurden Modagile-spezifische Test-DSLs entwickelt, welche alle wesentlichen Aspekte von Unit- und UI-Tests ausdrücken können. Dazu wurden Xtext-basierte Parser entwickelt, welche die entwickelten Test-Dateien verarbeiten können. Darauf aufbauend wurden Transformationswerkzeuge entwickelt, welche Tests für die jeweiligen Zielplattformen erzeugen können. Das vorliegende Dokument erläutert die Phasen und Bestandteile der plattformspezifischen Generierung. Tests sind ein wichtiges Mittel, um die Qualität von Programmcode sicherzustellen. Dies gilt auch für die modellgetriebene Multi-Plattform-Entwicklung. Durch die Verwendung plattformunabhängiger Test-DSLs wird die Effizienz bei der Entwicklung und Wartung von Tests reduziert. 6 Literaturverzeichnis [1] N. Kaiser, Eine DSL zum szenariobasierten Testen mobiler Anwendungen, Institut für Programmstrukturen und Datenorganisation, Karlsruhe, ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 11

12 ModAgile Mobile L8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 12