Das Test-Framework JUnit ETIS SS04
Gliederung Motivation TestFirst Grundlagen Assert TestCase Lebenszyklus TestCase UML-Diagramm TestCase TestSuite Zusammenfassung 2
Motivation (I) Kostspielige Folgen von Fehlern in Software SOMIT: Testen wichtig!!! ABER: fast keiner tut es Vorurteile: Keine Zeit, ABER: Tests stabilisieren Code Keine Lust, ABER: Testen ist kreativ + schafft Vertrauen zum Programm Mein Code ist fehlerfrei, ABER: Auswirkungen von Verbesserungen auf alten Code? Testabteilung testet, ABER: Je früher Fehler erkannt, desto besser 3
Unit - Tests Motivation (II) Test einzelner Komponenten White-Box-Tests Anforderungen an Test - Frameworks: Test- und Anwendungscode getrennt (Größe/Übersicht) Testfälle unabhängig ausführbar (Fehler finden) Testergebnis schnell erkennbar JUnit erfüllt diese Anforderungen 4
Motivation(III) JUnit: Open source Framework Schreiben und Ausführen automatischer Unit Tests unter Java Version 3.8.1 (http://www.junit.org/) In jeder gängigen Java-IDE verwendbar Autoren: Kent Beck (Extreme Programming) Erich Gamma (Mitglied Gang of Four - Design Pattern) Entsprechende Frameworks für gängige Programmiersprachen erhältlich 5
Motivation(IV) JUnit in eclipse 6
Ziel: TestFirst (I) Qualitätssicherung: Testbarkeit, Einfachheit Vorgehen: Vor eigentlicher Codierung Test schreiben Erst wenn Test fehlerfrei, dann ist Code fertig Nur soviel Produktionscode wie Test verlangt Kleine Schritte (abwechselnd Test- und Produktionscode) Vor Integration in Gesamtsystem muss Unit Test erfolgreich sein 7
Vorteile: TestFirst (II) gesamter Code ist getestet (Zerstörung funktionierenden Codes sofort entdeckt) Tests dokumentieren Code Schnelles Feedback durch kurze Wechsel Erzeugung von Test- und Produktionscode Einfaches Design, da durch Test bestimmtes Design Vorsicht: Wenn nur triviale Testfälle betrachtet, nutzen Tests wenig... 8
Grundlagen Einbinden der Testklasse in JUnit durch ableiten von Framework- Basisklasse junit.framework.testcase jede Testklasse erhält Konstruktor für Namen des auszuführenden Testfalls JUnit erkennt Methode als Testfall, da sie Konvention public void test..() folgt mit assert- Methoden, z.b. asserttrue(...) kann man Bedingungen testen bei Fehlerfall bricht JUnit laufenden Testfall mit AssertionFailedError ab 9
Assert (I) Klasse Assert definiert Tests von Werten und Bedingungen, die erfüllt sein müssen, Beispiele: Test, ob Bedingung wahr asserttrue(boolean condition) asserttrue(fritz.isradiostation) Test, ob zwei Objekte gleich (über equals- Methode) assertequals(object expected, Object actual) assertequals( JUnit, J + Unit ) 10
Assert (II) Test, ob zwei Fliesskommazahlen gleich sind (bei festzulegender Toleranz) assertequals(double expected, double actual, double delta); assertequals(3.00, 2.995, 0.005); Test, ob Objektreferenz null assertnull(hashmap.get(key)); Test, ob zwei Referenzen auf selbes Objekt verweisen assertsame(bar, hashmap.put( foo, bar).get( foo )); 11
TestCase (I) Ausführung Testfälle auf fixem Satz zu testender Objekte (Test - Fixture) Pro Testfallmethode meist nur bestimmte Operation der Fixture getestet Alle Testfälle einer Testklasse sollen von gemeinsamer Fixture Gebrauch machen 12
TestCase (II) Damit fehlerhafte Testfälle andere Testfälle nicht beeinflussen: Test - Fixture neu initialisieren Testklasse erbt von TestCase Test-Fixture Instanzvariablen in Testklasse Methode setup() überschreiben, um Instanzvariable zu initialisieren Methode teardown() überschreiben, um Ressouren (DB- Verbindung u.ä.) freizugeben setup() wird vor Ausführung eines Testfalls aufgerufen, teardown() danach 13
TestCase (III) public class EuroTest extends TestCase{ private Euro two; public EuroTest(String name){ } super (name); } protected void setup(){ two = new Euro(2.00); } protected void teardown(){ } 14
Lebenszyklus TestCase 1. Testframework sucht in Testklassen nach öffentlichen Methoden, ohne Parameter und Rückgabewert, die mit test beginnen (Reflection) 2. Sammeln der Methoden in Testsuite + unabhängige Ausführung 3. Für jeden Testfall neue Instanz der Testklasse und damit Test-Fixture erzeugen, um Seiteneffekte zu vermeiden 4. Vor Ausführung Testfall setup() aufgerufen (falls neu definiert) 5. test-methoden ausgeführt 6. Nach Test teardown (falls neu definiert) 7. Schritte ab 3 wiederholen, bis alle Testfälle einmal ausgeführt 15
UML Diagramm TestCase JUnit-Framework Assert asserttrue() assertequals() assertnull()... TestCase setup() teardown() EigenerTest testmethode() 16
TestSuite (I) Dient dem Zusammenfassen von Tests Suite: TestSuite- Objekt, dem beliebig viele Tests und Testsuiten hinzugefügt werden können In statische suite - Methode definiert, welche Tests zusammen auszuführen sind public static Test suite(){ } TestSuite suite = new TestSuite(); suite.addtestsuite(costumertest.class); suite.addtestsuite(movietest.class); return suite; 17
TestSuite(II) Komposite Pattern <<interface>> Test 1..n TestCase TestSuite tests 18
Zusammenfassung JUnit: Framework für Test von Java - Programmen Dient Test von Komponenten Unit Tests sind Investition in die Zukunft erleichtert es, dem Testcode gleiche Aufmerksamkeit wie Programmcode widmen 19
Literatur http://www.frankwestphal.de/unittestingmitjunit.html Johannes Link, Unit Tests mit Java, dpunkt.verlag, 2002 Barbara Beenen, Einführung in JUnit- Rot - grünes Wechselspiel, javamagazin, 05/04 Backschat, M., Edlich, J2EE - Entwicklung mit Open - Source- Tools, Spektrum Akademischer Verlag, München, 2004 20