Testen mit JUnit. Seminar Arbeit von Wang Jian, Ia00. Fachhochschule Aargau Departement Technik Studiengang I Betreuender Dozent: Prof. Dr. D.

Transkript

1 Testen mit JUnit Seminar Arbeit von Wang Jian, Ia00 Fachhochschule Aargau Departement Technik Studiengang I Betreuender Dozent: Prof. Dr. D. Gruntz Windisch, 12. Februar 2003 Jian Wang, Ia00 11.Feb.2002 Seite 1/15

2 Inhaltverzeichnis Abstract... 3 Einleitung Aufbau des Frameworks JUnit Kochrezept mit Eclipse Installation von JUnit Ampel-Project Setup Testfälle Schreiben Simple Test Modell Der erste Testlauf Fixture Modell TestSuite Modell... 9 Schluss Anhang (Source-Code des Beispiels) Literaturverzeichnis Jian Wang, ia00 11.Feb.2002 Seite 2/15

3 Abstract JUnit framework is the de facto standard unit testing API for Java development, which makes it possible, to write and run-repeatable tests easily. JUnit tests do not require human judgment to interpret, the test results are verified by a comprehensive assertion facility provided by the framework. One can also let many of tests run at the same time. Being integrated in development tools, it allows executing test cases as part of the build process, therefore along the coding progress, programmers can quickly catch the new bugs with tests, and fix them. JUnit is so easy to learn that with a remarkably small investment developing software becomes faster, more reliable, more predictable, and less stressing. Jian Wang, Ia00 11.Feb.2002 Seite 3/15

4 Einleitung Software Bugs kosten uns viel: Zeit, Geld und Frust. Wie kann man dies vermeiden? Die Antwort weiss jeder Programmierer: Der erstellte Code muss laufend getestet werden. Aber wenige tun es, weil sie sich zu sehr beeilen müssen. Dies führt aber bald in einen Teufelskreis: Je grösser der Zeitdruck, desto weniger Tests werden geschrieben. Je weniger Tests geschrieben werden, desto unstabiler wird der Code sein. Je unstabiler der Code ist, desto mehr Fehlermeldungen werden vom Kunden beanstandet. Umso unproduktiver arbeitet der Programmierer. Je unproduktiver der Programmierer arbeitet, desto grösser wird der Zeitdruck. extreme Programming Um diesen Teufelskreis entgegenzuwirken fördert Extreme Programming(XP) die Durchführung von Unit- Tests und macht diese zu einer wichtigen Tätigkeit im Software-Entwicklungszyklus. XP ist ein leichtgewichtiger Entwicklungsprozess, welche dem Kunden die volle Macht über Richtung und Richtungswechsel eines Projektes zurückgibt. Auch entfallen administrativ schwerfällige Analysen und die eigentliche Arbeit kann auf die Code-Erstellung konzentriert werden. Ein wichtiger Punkt in XP ist das schnelle Feedback, ob unser Code das tut, was er tun soll. Dies wird mit umfangreichen Tests auf zwei Ebenen erreicht. Unit Tests auf Komponenten-Ebene sichern die Qualität der eigenen Software und die der Kollegen. Akzeptanztests auf Gesamtprojekt-Ebene kontrollieren die Funktionalität des Gesamtsystems aus Sicht der Anwender. Der gute Ansatz in der Praxis für ein schnelles Feedback auf der Komponenten-Ebene ist die Entwicklung in kleinen Iterationsschritten: Ein wenig codieren, ein wenig testen, ein wenig codieren, ein wenig testen. Die nicht automatisierte Ausführung, Interpretation und Analyse der einzelnen Unit Tests ist nicht denkbar. Schreiben der Automatisierten Tests Ein allgemeiner Weg Test-Fälle zu schreiben ist eine main() Methode zu erzeugen. Zu Beginn werden die Klassen instanziert. Die Methoden der Klassen werden aufgerufen, die Rückgaben werden typischerweise mit System.out.println() auf dem Bildschirm angezeigt. Man prüft danach, ob diese Ausgaben mit den Erwartungen übereinstimmen. Diese Testmethode hat Beschränkungen: 1.Es gibt keine vollständige Automatisierung. Das Ergebnis von jedem Testablauf muss manuell interpretiert und analysiert werden. 2.Der Erfolg oder Misserfolg der Testausführung ist nicht auf einen Blick erkennbar. 3.Es können nur einige wenige Klassen auf einmal getestet werden. 4.Ein Programm mit zu vielen Print-Out-Statements verursacht die unübersichtlichen und hässlichen Scroll Blindness. Alle diese Nachteile versucht JUnit Framework zu beheben. Dieses Framework zur Automatisierung von Unit Tests in Java wurde ursprünglich von Kent Beck und Erich Gamma entwickelt und wird als Open- Source-Projekt von Sourceforge weiterentwickelt. Mittlerweile ist JUnit zum Quasistandard als Java-Unit- Testing-Werkzeug geworden, und in vielen IDEs eingebunden wie z.b. Eclipse, Forte, JBuilder, Together etc. In diesem Bericht werden wir zuerst die Architektur des JUnit Frameworks betrachten. Anhand eines Beispiels werde ich noch die grundlegenden Arbeitsschritte, wie man Testfälle mittels Junit und Eclipse schreiben kann, illustrieren. Jian Wang, ia00 11.Feb.2002 Seite 4/15

5 1. Aufbau des Frameworks JUnit Framework ist ein grossartig Design-Pattern-intensives Beispiel. Die Abbildung 1 zeigt einen Überblick über die Kernpatterns im Framework. Wir werden aber hier nicht auf alle Details eingehen, sondern nur auf die aus der Benutzersicht wichtigsten Punkte. Das Interface Test und die zwei Klassen, TestCase und TestSuite zusammen haben das Composite-Pattern realisiert. Dieses Pattern ermöglicht dem Programmierer, viele unterschiedliche Testfälle leicht zusammenstellen und gleichzeitig laufen zu lassen. Test: Composite(Component). Ist das Interface, wo alle Typen von Unit-Test-Klassen implementieren müssen. Die Implementierungs-Klassen im Framework sind TestCase und TestSuite. TestCase: Composite(Leaf). Ist die zentrale Abstraktklasse, von welcher die User-Definierte Testfälle-Klassen erweitern können. TestSuite: Composite(Composite). Enthält eine Zusammenstellung von Test Objekten: TestCase, andere TestSuite oder die Benutzer eigene Implementation von dem Interface Test oder alle mögliche Kombinationen davon. TestResult:Collecting Parameter. Akkumuliert das Ergebnis von jedem Testablauf, wie Failures und Errors. Sie ist ein Erweiterungspunkt des Frameworks. Benutzer können weitere TestResult schreiben, um eigene Interpretation von Ergebnis zu definieren. Abb. 1 JUnit Patterns Übersicht Jian Wang, Ia00 11.Feb.2002 Seite 5/15

6 2. JUnit Kochrezept mit Eclipse Nun wie verwendet man Junit? Um die Arbeitsweise besser zu beleuchten, nehme ich ein AmpelModell als Beispiel. Das AmpelModell hat drei Lichter: Rot, Gelb und Grün. Durch das Drücken eines Knopfs auf dem GUI, schaltet die Ampel zyklisch in der Folge von rot, rot + gelb, grün, gelb und wieder rot um. Die Klasse hat folgende Methoden: public boolean getred(); public boolean getyellow(); public boolean getgreen(); public void setred(boolean b); public void setgreen(boolean b); public void setredyellow(boolean b); public void setyellow(boolean b); public void step(); // prüft ob das Rot-Licht an ist // prüft ob das Gelb-Licht an ist // prüft ob das Grün-Licht an ist // setzt die Ampel in rot // setzt die Ampel in grün // setzt die Ampel in rot+yellow // setzt die Ampel in gelb // schaltet die Ampel um public void addpropertychangelistener(propertychangelistener l); Beginnen wir ganz am Anfang - bei der Installation Installation von JUnit Die jeweils aktuelle JUnit-Version kann man von herunterladen. In seinem ZIP-Archiv werden ausser der benötigten JAR-Datei src.jar auch noch Beispiele und Tests für das Framework selbst geliefert. Dann in Eclipse 1.Lege neues Java-Projekt junit an. 2.File Import..., Zip file, Browse..., src.jar wählen. 3.Die nötige Packages wie in der Abb.2 gezeigt wählen: junit.extensions, junit.framework, junit.runner und junit.textui. 4.Wähle das src Verzeichnis von der junit- Projekt als die Destination for imported resources. Und Finish drücken. Abb. 2 JUnit Packages zu importieren 2.2 Ampel-Project Setup Lege ein neues Java-Projekt ampel für unser Beispiel an. In 'File Properties', das Projekt junit in 'Java Build Path Projects' übernehme. Siehe Abb. 3. Abb. 3 JUnit im Build Path zu übernehmen 2.3 Testfälle Schreiben Unter Umstände kann man die Testfällen-Gestaltung unterschiedlich strukturieren. Hier werden die drei meist gebrauchten Arten beschrieben. 1. Simple Test Modell 2. Test Fixture Modell 3. Test Suite Modell Jian Wang, ia00 11.Feb.2002 Seite 6/15

7 2.3.1 Simple Test Modell Bei 'Simple Test Modell' ist ein Testfall zu schreiben wie der Name sagt sehr einfach: 1. Generiere eine Subklasse von Junit.framework.TestCase. 2. Erstelle eine oder mehrere public void parameterlosen Test-Methoden. Damit diese Methoden von JUnit automatisch aufgegriffen werden, müssen ihre Namen mit dem Prefix, test beginnen. 3. Um die Ergebnisse zu verifizieren, stehen in JUnit zahlreiche Assertion-Facilities zur Verfügung. Wir schreiben jetzt einen Testfall, in dem wird die erste Anforderung unseres Beispiels überprüft, wobei ein neues AmpelModell-Objekt immer mit dem Zustand rot beginnen soll: import junit.framework.*; public class AmpelModellSimpleTest extends TestCase { public void testnewampel() { AmpelModellSimple a = new AmpelModellSimple(); asserttrue(a.getred()); assertfalse(a.getyellow()); assertfalse(a.getgreen()); Die Methode asserttrue() überprüft zur Laufzeit den boolean-ausdruck. Ergibt sich der Wert als false, so bricht der Testfall an dieser Stelle ab, ein Failure wird registriert und der nächste Test, falls vorhanden, wird gestartet. Der Name der Testklasse setzt sich per Konvention aus dem Namen der Zielklasse und der Endung Test zusammen. So kann das automatisierte Erkennen und eventuelle Entfernen von Testklassen erleichtert werden Der erste Testlauf Lassen wir nun diesen Testfall laufen beim Wählen des 'Run As JUnit Test' im Hauptmenü. Der JUnit View signalisiert mit einem roten Balken mit einer Reihe von Fehlern. Oben im Fenster wird die Anzahl der durchgeführten Tests, der dabei geworfenen Java-Exceptions sowie der fehlgeschlagenen Testfälle angezeigt. Im mittleren Bereich des JUnit Views findet man unter dem Reiter 'Failures' die Liste der fehlgeschlagenen Tests. Der Reiter 'Hierarchy' gibt eine Übersicht aller durchgeführten Tests. Der untere Bereich 'Failure Trace' zeigt den Call Back beim Ausführen fehlerhafter Test an. JUnit unterscheidet zwischen Failure und Error. Das Vorkommen eines Failures ist vorauszusehen, und wird mit der Assertions kontrolliert. Errors sind unerwartete Probleme wie zum Beispiel eine NullPointerException. Unter Failure Trace-Bereich in Abb. 4 ist die Fehlermeldung, Abb.4 JUnit View (asserttrue) die von der Methode asserttrue() ausgelöst wurde, nicht gerade sehr hilfreich. Wenn wir anstatt eine andere Methode assertequals() wie im folgenden Beispiel verwenden, bekommen wir einen JUnit View wie in Abb. 5 aufgezeigt. public void testnewampel() { AmpelModell a = new AmpelModell(); Jian Wang, Ia00 11.Feb.2002 Seite 7/15

8 assertequals( true, a.getred()); assertequals( false, a.getyellow()); assertequals( false, a.getgreen()); Bei der Fehlermeldung wird jetzt die Fehlerursache genauer aufgeführt (Abb. 5): expected: <true> but was: <false> Abb.5 JUnit View (assertequals) mit genauer Fehlermeldung Für die weiteren Assertion-Facilities, kann man in der JUnit API Dokumentation nachschlagen. Nachdem wir alle fehlerhaften Implementierungen korrigiert haben, signalisiert JUnit View dies mit einem grünen Balken Fixture Modell In der Praxis ist es oft so, dass wir eine Menge von Tests haben, die sich auf dasselbe oder ein ähnliches Set von Objekten beziehen. Um das Duplizieren des Codes zur Initialisierung dieser Objekte zu vermeiden, können sie in eine so genannte Test-Fixture zusammen erstellt werden. Jeder Test kann dann eigene, leicht unterscheidende Nachrichten oder Parameter an die Test-Fixture geben, und die unterschiedliche Ereignis kontrollieren. JUnit bietet eine Möglichkeit, den Code, der zur Erzeugung der Fixture benötigt wird, in die Methode setup() auszulagern. Nach dem Ausführen eines Tests Ressourcen wie zum Beispiel eine geöffnete Datei, Datenbank-Verbindungen können in einer Methode teardown() freigegeben werden. Der Lebenszyklus eines Testfalls läutet folgendermassen ab: 1. setup() wird ausgeführt. 2. eine Testmethode wird aufgegriffen. 3. teardown() wird aufgerufen. 4. wiederholt die obere Schritten für jede Testmethode. Dadurch wird gewährleistet, dass die Veränderungen, die ein Testfall auf Objekte der Fixture hat, keine Auswirkungen in einem anderen Testfall zeigen. Als Beispiel erweitern wir die AmpelModell-Klasse so, dass sie in einem GUI benutzt werden kann. Dazu muss die Möglichkeit bestehen, Änderungen des internen Zustands zu erkennen und entsprechend zu reagieren. Wir verwenden hier den java.beans.propertychangelistener. Unsere Tests werden prüfen ob die entsprechenden Events richtig ausgelöst werden. Der Einbau einer Fixture in der Testklasse sieht so aus: public class AmpelModellEventTest extends TestCase { private AmpelModellEvent ampel; private boolean gotevent; protected void setup() { Jian Wang, ia00 11.Feb.2002 Seite 8/15

9 ampel = new AmpelModellEvent(); ampel.addpropertychangelistener(new PropertyChangeListener() { public void propertychange(propertychangeevent evt) { gotevent = true; ); protected void teardown() { /*wir haben keine ständige Resource gebraucht */ // Das setzen des selben Werts keinen Event generieren soll. public void testnoevent() { ampel.setred(ampel.getred()); assertequals(false, gotevent); // prüft ob das Ändern des roten Lichts ein Event auslöst. public void testredevent() {... //prüft ob ein Event auslöst nach jedem step(). public void teststeptriggerevent() {... Wie gesehen, das Objekt Ampel ist als Instanz-Variabel deklariert, auf die von allen Tests aus zugegriffen werden kann. Die Methode setup() wurde überschrieben um die Variablen zu initialisieren. Da wir keine ständigen Ressourcen zugeteilt haben, machen wir nichts in der Methode teardown(). Nachdem die Fixture aufgebaut ist, haben wir drei Testmethoden hinzugefügt. Im Beispiel oben zeigt, wie die Testmethode testnoevent() mit der Fixture interagiert durch das Aufrufen der getter- und setter- Methoden des ampel-objektes TestSuite Modell Wenn wir die obige Testklasse laufen lassen, wird der TestRunner per Default alle TestMethoden der Klasse aufgreifen. Es gibt aber noch eine andere Variante, TestSuite Modell. Dieses Modell wird auch als Dynamic Testrunning bezeichnet. Die benötigten Tests können in einer TestSuite zusammengefasst werden, dadurch kann der Programmierer aus eigenen Wünschen selbst die Tests gestalten. Dazu brauchen wir zusätzlich nur noch einen Konstruktor mit String als Eingabe, und eine Implementierung von einer statischen Methode suite(). public AmpelModellEventTest(String name) { super(name); public static Test suite() { TestSuite suite = new TestSuite(); suite.addtest(new AmpelModellEventTest("testNoEvent")); suite.addtest(new AmpelModellEventTest("testRedEvent")); suite.addtest(new AmpelModellEventTest("testStepTriggerEvent")); return suite; Die Methode addtest() erlaubt das Hinzufügen von Tests zu einer Suite. Ein einzelner Testfall wird über den Konstruktor der Testfall -Klasse erzeugt. Als Parameter ist der Name von einer der zum Laufenden Test- Methoden. Durch Reflektion kann der TestRunner dann dynamisch die Methoden aufrufen. In der Praxis haben wir nicht nur eine oder zwei Testklassen. Statt jeweils einzelne Testklasse nacheinander als JUnit Test aufzurufen, ist es sinnvoll alle Testfälle mit einem Befehl zu starten. Diese ermöglicht JUnit mit seinem Composite-Pattern-Design. Durch alle Testfälle zu einer TestSuite zusammenzufassen, alle in der Suite befindliche Tests werden in der Reihenfolge des Hinzufügens ausgeführt. Das Zufügen der Testfälle ist ähnlich wie das Beispiel oben, ausserdem als Parameter wird einem Klassen-Objekt ( AmpelModellSimpleTest.class ) verwendet. Jian Wang, Ia00 11.Feb.2002 Seite 9/15

10 Eine solche TestSuite kann in Eclipse sehr leicht mit File New, Other..., Java, JUnit, TestSuite erzeugt werden. Defaultmässig wird eine neue Klasse AllTests erstellt, und alle sich in der gleichen Package befindende Testfällen werden automatisch angehängt. import junit.framework.test; import junit.framework.testsuite; public class AllTests { public static Test suite() { TestSuite suite = new TestSuite("Test for ampelmodell"); suite.addtest(new TestSuite(AmpelModellSimpleTest.class)); suite.addtest(new TestSuite(AmpelModellStepTest.class)); suite.addtest(new TestSuite(AmpelModellEventTest.class)); return suite; Lassen wir die AllTests-Klasse als JUnit Test laufen, bekommen wir einen JUnit View wie in Abb. 6 erscheint. Was hier besonders interessant ist, ist dass unter dem Reiter Hierarchy des JUnit Views alle Tests, die TestSuite enthält, angezeigt werden. Abb.6 Testsuite Hierarchie im JUnit View Schluss Nach der Begründung der Notwendigkeit von Automatisierten Testen, haben wir anhand eines kurzen Beispiels den Automatisierungsframework Junit kennen gelernt. JUnit ermöglicht Ein übersichtliches Testergebnis. Beliebige Zusammenfassung von Tests in Testsuiten. Die Unabhängigkeit der Testfälle, durch die Gemeinsamkeit von Tests in Test-Fixtures auszulagern. Die leichte Trennung von Testcode und Produktionscode, da alle Testfälle in einer eigenen Klassenhierarchie erstellt werden erweitern von der Basisklasse junit.framework.testcase. Als der de facto Standard Java-Unit-Test-API, ist JUnit in diversen IDEs eingebunden. Jian Wang, ia00 11.Feb.2002 Seite 10/15

11 Anhang (Source-Code des Beispiels) 1. Anwendungscode 1.1 AmpelModellSimple.java package ampelmodell; public class AmpelModellSimple { // prüft ob das Rot-Licht an ist public boolean getred() { return true; // return false; // fehlerhafte Zuweisung // prüft ob das Gelb-Licht an ist public boolean getyellow() { return false; // prüft ob das Grün-Licht an ist public boolean getgreen() { return false; 1.2 AmpelModellEvent.java package ampelmodell; import java.beans.propertychangesupport; import java.beans.propertychangelistener; public class AmpelModellEvent { // RED = 0x001, YELLOW = 0x010, RED-YELLOW = 0x011, GREEN = 0x100 private static final int RED = 1, YELLOW = 2, GREEN = 4; private int lights = RED; public AmpelModellEvent() { lights = RED; // prüft ob das Rot-Licht an ist public boolean getred() { return (lights & RED) == RED; // prüft ob das Gelb-Licht an ist public boolean getyellow() { return (lights & YELLOW) == YELLOW; // prüft ob das Grün-Licht an ist public boolean getgreen() { return (lights & GREEN) == GREEN; /** Methode step schaltet den Ampelzustand jeweils um. * Diese ist aber Bug-haftet im GUI. */ // public void step() { // switch(lights) { // case RED: // lights = RED + YELLOW; // break; // case RED+YELLOW: // lights = GREEN; // break; // case GREEN: // lights = YELLOW; // break; // case YELLOW: // lights = RED; // break; // default: throw new RuntimeException("Illegaler Ampelzustand: " + lights); // // // /** Methode step schaltet den Ampelzustand jeweils um. * Diese ist die Bug-freie Implementierung. */ public void step() { Jian Wang, Ia00 11.Feb.2002 Seite 11/15

12 switch(lights) { case RED: setyellow(true); break; case RED+YELLOW: setred(false); setyellow(false); setgreen(true); break; case GREEN: setyellow(true); setgreen(false); break; case YELLOW: setred(true); setyellow(false); break; default: throw new RuntimeException("Illegaler Ampelzustand: " + lights); // Das Ändern des Lichts soll ein Event auslösen. private PropertyChangeSupport pcs = new PropertyChangeSupport(this); public void addpropertychangelistener(propertychangelistener l) { pcs.addpropertychangelistener(l); /** Die setter-methoden lössen Propertyänderungen aus. */ public void setred(boolean b) { if (getred() ^ b) { lights ^= RED; pcs.firepropertychange("red",!b, b); public void setgreen(boolean b) { if (getgreen() ^ b) { lights ^= GREEN; pcs.firepropertychange("green",!b, b); public void setredyellow(boolean b){ if ((getred() && getyellow()) ^ b) { lights ^= RED+YELLOW; pcs.firepropertychange("red-yellow",!b, b); public void setyellow(boolean b){ if (getyellow() ^ b) { lights ^= YELLOW; pcs.firepropertychange("yellow",!b, b); 2. Testcode 2.1 AmpelModellSimpleTest.java package test.ampelmodell; import ampelmodell.ampelmodellsimple; import junit.framework.testcase; Jian Wang, ia00 11.Feb.2002 Seite 12/15

13 public class AmpelModellSimpleTest extends TestCase { // prüft ob ein neues AmpelModell-Objekt mit dem Zustand rot beginnt. public void testnewampel() { AmpelModellSimple a = new AmpelModellSimple(); // asserttrue und assertfalse werden verwendet // asserttrue(a.getred()); // assertfalse(a.getyellow()); // assertfalse(a.getgreen()); // // assertequals wird verwendet. assertequals(true, a.getred()); assertequals(false, a.getyellow()); assertequals(false, a.getgreen()); 2.2 AmpelModellEventTest.java package test.ampelmodell; import ampelmodell.ampelmodellevent; import junit.framework.test; import junit.framework.testcase; import junit.framework.testsuite; import java.beans.propertychangelistener; import java.beans.propertychangeevent; public class AmpelModellEventTest extends TestCase { // Instanz-Variablen deklarieren private AmpelModellEvent ampel; private boolean gotevent; // Instanz-Variablen Initializieren protected void setup() { ampel = new AmpelModellEvent(); ampel.addpropertychangelistener(new PropertyChangeListener() { public void propertychange(propertychangeevent evt) { gotevent = true; ); // Da wir keine ständige Resourcen alloziert haben, machen wir nichts. protected void teardown() { // do nothing // Constructor AmpelModellEventTest. public AmpelModellEventTest(String name) { super(name); // Die Tests können in eine TestSuite zusammengefasst werden. public static Test suite() { TestSuite suite = new TestSuite(); suite.addtest(new AmpelModellEventTest("testNoEvent")); suite.addtest(new AmpelModellEventTest("testRedEvent")); suite.addtest(new AmpelModellEventTest("testStepTriggerEvent")); return suite; // Das setzen des selben Werts soll keinen Event auslösen. public void testnoevent() { ampel.setred(ampel.getred()); assertequals(false, gotevent); // prüft ob das Ändern des roten Lichts ein Event auslöst. public void testredevent() { ampel.setred(!ampel.getred()); Jian Wang, Ia00 11.Feb.2002 Seite 13/15

14 assertequals(true, gotevent); //prüft ob nach jedem step() ein Event ausgelöst wird. public void teststeptriggerevent() { for (int i=0; i<5; i++) { gotevent = false; ampel.step(); assertequals(true, gotevent); Jian Wang, ia00 11.Feb.2002 Seite 14/15

15 Literaturverzeichnis JUnit Project Homepage: Kent Beck, Erich Gamma: JUnit: A Cook s Tour. Kent Beck, Erich Gamma: Test-Infected: Programmers Love Writing test. Kent Beck, Erich Gamma: JUnit Cookbook. Erik Hatcher and Steve Loughram: Java Development with Ant, Manning Publications Co, August 2002, Chapter 4: Testing with JUnit Johannes Link: Unit Tests mit Java, Der Test-First-Ansatz, dpunkt Verlag, 2002 ISBN: extreme Programming Homepage: Eclipse Tutorial mit JUnit, (Die Herkunft meines Beispiels AmpelModell) : Jian Wang, Ia00 11.Feb.2002 Seite 15/15