Programmierpraktikum Java Entdecken. Merkblatt 3

Transkript

1 Technische Universität München Fakultät für Informatik Prof. Dr. Helmut Seidl Michael Petter Melanie Dietz Raphael Geissler SS 2005 Programmierpraktikum Java Entdecken 1 extreme Programming Merkblatt 3 extreme Programming extreme Programming ist die Bezeichnung eines relativ neuen Prozesses der Softwareentwicklung. Erstmals wurde diese Methodik in [1] veröffentlicht. Miterfinder dieser Entwicklungsmethodik sind Ward Cunningham und Ron Jeffries. Trotz seines jungen Alters gehört XP heutzutage zu den bekanntesten Softwareentwicklungsprozessen. 1.1 Philosophie Grundlegend für XP ist die Erkenntnis, dass zum Projektbeginn meistens die wirklichen Anforderungen an eine Software noch nicht bekannt sind. In den herkömmlichen Entwicklungsprozessen sind Änderungen an der Spezifikation jedoch nur während der Planungsphase, also am Projektbeginn, vorgesehen. Danach haben sie eine erhebliche Verzögerung und Kostensteigerung des Projekts zur Folge. 1.2 Die Eckpfeiler XP versucht nun durch das Zusammenspiel verschiedener Maßnahmen die Qualität des Entwicklungsprozesses soweit anzuheben, dass Änderungswünsche auch in fortgeschrittenem Projektstadium mit geringem Aufwand integriert werden können (siehe Abb. 1). Diese Maßnahmen lauten: 1. Pair-Programming - zwei Programmierer teilen sich eine Tastatur und Monitor - einer codiert, einer denkt mit. 2. Integration ( Codeverwaltung)der einzelnen Komponenten zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen ( ANT). 1

2 Abbildung 1: entnommen aus 3. Testgesteuerte Programmierung - es werden erst die Unit-Tests geschrieben, bevor die eigentliche Funktionalität programmiert wird. Die Tests werden nach jedem Programmierschritt ausgeführt und liefern Rückmeldung über den Entwicklungsstand. Man spricht auch von Grey-Box-Tests ( JUnit). Generell gilt, dass Komponenten nur dann in das Gesamtsystem integriert werden dürfen, wenn die zugehörigen Test erfolgreich durchlaufen werden. Nebenbei entsteht durch die Funktionalitätstests eine zusätzliche Dokumentationsquelle. 4. Enge Einbeziehung des Kunden, d.h. der Kunde gibt das Iterationsziel mit Hilfe sogenannter Story-Cards vor und hat sofort die Möglichkeit Akzeptanztests durchzuführen. Story-Cards beschreiben Anwendungsfälle exemplarisch in Form kurzer Geschichten. Der Kunde muss sehr oft anwesend oder zumindest greifbar sein. 5. Laufende Refaktorisierung, ständige Architekturverbesserung Stunden-Woche, denn Überstunden mindern die Freude an der Arbeit, mittelfristig die Konzentrationsfähigkeit der Programmierer und somit auch die Qualität des Produkts. 7. Kurze Release-Zyklen, um dem Kunden in regelmäßigen Zeitabständen einen lauffähigen Zwischenstand des Produkts zu liefern. Weitere Informationen sind im Wikipedia 1 zu finden. 1.3 Relevanz für das Praktikum Im Praktikum soll nach Möglichkeit anhand der XP Methodik entwickelt werden, daher auch die Gruppengrößen von 2 Teilnehmern. Von den unter 1.2 genannten Punkten sind, bis auf die 40 Std. Woche, alle in die Praxis umzusetzen. In Java existiert für Punkt (3) das Paket JUnit, 1 Programming 2

3 mit dessen Hilfe die geforderten Testfälle sehr schnell geschrieben und durchgeführt werden können. 2 Automatisiertes Testen 2.1 Theorie Ein wichtiger Eckpfeiler von extreme Programming ist das automatisierte Testen. Leider fällt dieser Punkt bei Zeitdruck oft dem Rotstift zum Opfer, obwohl eine kontinuierliche und konsequente Durchführung von Tests am Ende sehr viel Zeit, Änderungen und Hacks erspart. Generell gibt es in der Softwareentwicklung vier Kategorien von Tests. Einheiten-Tests Diese Tests bilden generell den Anfang aller Testläufe. Hier wird der Code einer funktionalen Einheit auf Fehler überprüft. Normalerweise werden dabei alle öffentlich zugänglichen Methoden und Attribute nacheinander aufgerufen und mit erwarteten Ergebnissen verglichen. Dabei soll nicht jede mögliche Eingabekombination, sondern eher ein typisches Verhalten getestet werden. In XP gehören Einheiten-Tests zu den täglichen Aufgaben eines Programmiers, insbesondere da diese Tests vor dem eigentlichen Entstehen des Codes existieren müssen. Besteht ein solcher Einheitentest, wird die Einheit zum Projekt hinzugefügt und der Einheitentest an die Testsuite angehängt. Dadurch wächst diese immer weiter an, bis sie am Ende das komplette Projekt verifiziert. Integrationstests Einheiten-Tests sollten untereinander so unabhängig wie möglich geschrieben sein. Einheiten-Tests des Objekts A sollen ohne die Objekte B und C ausgeführt werden können, auch wenn diese drei Objekte ein interagierendes Subsystem bilden. Um nun Interaktionsund Kommunitkationsfähigkeiten dieses Subsystem zu testen, sind Einheiten-Tests ungeeignet. Stattdessen existieren für diese sogenannten Integrationstests eigene Frameworks, zum Beispiel Cactus für das Testen von J2EE Containern. Funktionstests Ist ein Projektmodul vollständig implementiert, muss geprüft werden, dass die Implementierung den Anforderungen des Auftraggebers gegenüber besteht. Diese geschieht mittels Funktions- oder auch Akzeptanztests, welche die Reaktionen des Moduls auf Anwendungsfälle überprüfen. Performanztests Schließlich ist eine noch so fehlerfrei geschriebene Software nutzlos, falls sie Zeitlimits mißachtet oder nicht mit der gegebenen Hardware funktioniert. Insbesondere Anwendungen aus dem Server/Client Bereich müssen im Hinblick auf Antwortzeiten und Skalierbarkeit kritisch getestet werden, da zwischen dem einen Tester und den hunderten bis tausenden Benutzern eine zu große Belastungsspanne liegt. Um nicht die Benutzer als Tester engagieren zu müssen, existieren Performanztests, die automatisch entweder skalierte Zeitlimits setzten oder auch automatisierte Anfragen senden. Zwei solche Tools sind JUnitPerf und JMeter. 3

4 2.2 Praxis: JUnit Begriffe JUnit baut Testumgebungen aus drei verschiedenen Komponenten auf. 1. Testmethoden bilden den Grundstein. In ihnen wird eine einzelne Reaktion überprüft, zum Beispiel das Hinzufügen eines Objektes in einen Container, oder das Finden des größten Wertes in einem int[]. Testmethoden erkennt man am Prefix test im Namen. Jede Methode, deren Namen diesen Prefix enthält, wird vom JUnit Framework automatisch ausgeführt. Beispiele: testadd(), testiterator(), Die nächste Komponente ist ein Testfall. Er wird durch eine benutzerdefinierte Klasse repräsentiert, die von junit.framework.testcase erbt. Ein Testfall enthält mehrere Testmethoden, die Gemeinsamkeiten besitzen. Zum Beispiel werden die Testmethoden aus (1) durch den Testfall ContainerTest zusammengefasst. Laut Konvention enthält der Name eines Testfalls das Postfix Test. Ein Testfall sieht in der Regel so aus, daß eine bestimmte Konfiguration von Objekten aufgebaut wird, gegen die der Test läuft. Diese Menge von Testobjekten wird auch als Test-Fixture bezeichnet. Pro Testfallmethode wird meist nur eine bestimmte Operation und oft sogar nur eine bestimmte Situation im Verhalten der Fixture getestet. 3. Mehrere Testfälle werden wiederum durch eine Test Suite zusammengefasst. Dabei spielt die Reihenfolge der Tests eine wichtige Rolle Testmethoden Zum Überprüfen werden innerhalb der Testmethoden Zusicherungen verwendet. Nachfolgende Liste bietet eine Überblick über die verfügbaren assert Methoden. asserttrue(boolean condition) verifiziert, ob eine Bedingung wahr ist assertequals(object expected, Object actual) verifiziert, ob zwei Objekte gleich sind. Der Vergleich der Objekte erfolgt in JUnit über die equals Methode. assertequals(int expected, int actual) verifiziert, ob zwei ganze Zahlen gleich sind. Der Vergleich erfolgt für die primitiven Java-Typen über den == Operator. assertequals(double expected, double actual, double delta) verifiziert, ob zwei Fließkommazahlen gleich sind. Da Fließkommazahlen nicht mit unendlicher Genauigkeit verglichen werden können, wird zusätzlich eine Toleranz erwartet. assertnull(object object) verifiziert, ob eine Objektreferenz null ist. assertnotnull(object object) verifiziert, ob eine Objektreferenz nicht null ist. assertsame(object expected, Object actual) verifiziert, ob zwei Referenzen auf das gleiche Objekt verweisen. 4

5 Eine Methode, die nicht zur Kategorie von Zusicherungen gehört, ist fail ( String message ) Sie lässt den Test sofort fehlschlagen, und wird insbesondere dazu verwendet Quelltext Bereiche zu kennzeichnen, die nie erreicht werden sollten (beispielsweise wenn eine Ausnahme erwartet wurde) Testfälle Für einen Testfall muss meistens eine bestimmte Konfiguration aufgebaut werden anhand der getestet werden soll. Dieses geschieht durch das Überschreiben der Methode protected void setup () Ihr Gegenstück zum Bereinigen von Verbindungen und Speicher lautet teardown(). Beim einfachen Erzeugen von Objektreferenzen in setup() muss teardown() nicht überschrieben werden, da in diesem Fall die Garbage Collection das Aufräumen übernimmt. Der Testfall erbt immer von TestCase. Weiterhin muss ein Konstruktor der Form public Testfall ( String method ) { super( method ); implementiert werden. Soll der Ausführautomatismus von Testmethoden aufgehoben werden, muss die Methode überschrieben werden. public static Test suite () 2.3 TestSuites Eine TestSuite ist, wie schon erwähnt, eine Sammlung von Testfällen. Diese können wiederum selber andere TestSuites sein. Dieses System ist auch unter dem Namen Composite Design Pattern bekannt. Ein einzelner Testfall wird automatisch ausgeführt. Wenn nun mehrere Testfälle nacheinander ausgeführt werden sollen, muss eine TestSuite Klasse erstellt werden. Sie sieht meistens folgendermaßen aus. package progprakt. junit; import junit. framework.*; 5 /** * TestSuite that runs several sample tests. */ public class MyTestSuite { public static void main ( String [] args ) { 10 junit.textui.testrunner.run ( suite () ); 5

6 public static Test suite ( ) { TestSuite suite = new TestSuite (" All my own tests."); 15 suite. add(new TestSuite ( ContainerTest.class)); suite.add( VectorTest.suite ()); return suite; 3 Literaturverzeichnis Natürlich bilden die bisher besprochenen Möglichkeiten nicht das ganze Spektrum von JUnit ab. Daher sind im Nachfolgenden noch einige Nachschlagewerke aufgeführt, die zum besseren Verständnis herangezogen werden können. Literatur [1] Kent Beck. Extreme Programming. Das Manifest. Addison-Wesley, ISBN [2] Steve Loughran Erik Hatcher. Java Development with Ant, chapter 4. Manning Publications Company, [3] Tammo Freese et al. Unit tests mit junit. [4] Richard Hightower. Java Tools for extreme Programming. Wiley Computer Publishing, ISBN X. [5] Andrew Hung. Unit-Tests mit JUnit. Hanser, ISBN [6] Stefan Matthias. Junit/eclipse. 6