Testgetriebene Entwicklung mit JUnit4

Transkript

1 Testgetriebene Entwicklung mit JUnit4 Seminarvortrag im Fach Fortgeschrittenes Programmieren in Java, Dozent: Prof. Klinker Datum: Referent: Marius Schmeding

2 Ausgangsfragen... Wie testet man eine Java-Applikation? Was hat man davon? Was ist Testgetriebene Entwicklung? Was hat man davon? Was versteht man unter Refactoring? Was hat man davon? Wie sieht Testgetriebene Entwicklung konkret aus?

3 1.JUnit Gliederung 1.Automatisiertes Testen 2.Einführung JUnit4 3.Testen in Eclipse 2.Testgetriebene Entwicklung 1.Die 3 Direktiven 1.Coding 2.Refactoring 3.Integration 3.Demonstration am Beispiel 1.Generierung von HAW-Stundenplänen 3

4 Wie testet man Software? Ausprobieren per Hand + schnell, wenn unverbindlich - aufwändig, wenn protokolliert - lästig, wenn wiederholt Ausprobieren per Code - aufwändig, da Testfälle programmiert werden müssen + einfache Protokollierung + kein Mehraufwand bei wiederholtem Testen, da automatisierbar 4

5 Welche Anforderungen an eine Software machen automatisiertes Testen erforderlich??? 5

6 Automatisiertes Testen von Code Testmethode ruft Methode(n) des Programmcodes auf und erwartet definiertes Ergebnis Testmethoden werden zu Testfall zusammengefasst Ablaufvarianten werden durch verschiedene Testfälle abgedeckt Testergebnisse werden dargestellt/protokolliert Test läuft unabhängig vom eigenltichen Programm ab 6

7 Schwierigkeiten beim automatisierten Testen Testmethoden erfordern zusätzlichen Code Programmcode muss testbar sein Testcode muss bei Änderung des Programmcodes angepasst werden Testcode kann fehlerhaft sein Testfälle müssen strukturiert werden (was will ich testen?) 7

8 Der Aufwand für den Testcode übersteigt scheinbar den Aufwand für den eigentlichen Programmcode. Ist das gerechtfertigt? 8

9 Den Aufwand gering halten Testwerkzeug benutzen Von Anfang an Tests implementieren Zum Beispiel: JUnit Testgetriebene Entwicklung 9

10 JUnit Ist eine Java-Bibliothek, die das Testen von Code unterstützt Open Source (CPL) Seit 1998 etabliert, aktuelle Version: JUnit4 In gängigen IDEs (Eclipse, Netbeans, etc.) standardmäßig integriert Mit ca Zeilen Code ziemlich winzig 10

11 JUnit Kernkonzepte Objekt Synonym Beschreibung Assert TestCase (TestFixture) TestSuite TestRunner Bedingender Vergleich Testfall Testgruppe Testdurchführung Testet z.b. eine Methode, indem es sie aufruft und einen definierten Rückgabewert vorraussetzt. Beinhaltet ein oder mehrere Asserts, um ein bestimmtes Verhalten eines Objektes zu testen. Führt eine Reihe von TestCases zusammen, um eine bestimmte (Teil-)Funktionalität des Programms zu prüfen. Startet die TestSuiten/TestCases und stellt die Ergebnisse dar. Ist in entsprechenden IDEs fest integriert. 11

12 JUnit4 Syntax Annotations @Before,... assert - Anweisung assert (engl.) = auf etw. bestehen wird auf Rückgabewerte angewandt assertequals(...), assertnull(...), assertnotnull(...), assertsame(...), assertnotsame(...) 12

13 Die Annotations im Testmethode (Testcase) Testmethode mit einer Exception markiert eine (Aufruf vor jedem Testfall) markiert eine (Aufruf nach jedem Testfall) markiert eine (Aufruf einmalig) markiert eine (Aufruf Class2.class) Testsuite 13

14 assertequals(...) assertequals( Polo, auto.tostring()) Prüft, ob ein Returnwert unserer Erwartung entspricht Alternativ: asserttrue(auto.tostring().equals( Polo )) Nachteil: Im Testdurchlauf werden Erwartungsund Istwert nicht ausgegeben assertarrayequals(...) für Arrays 14

15 Ein Test schlägt fehl Programmklasse public class Euro { private double wert; Testklasse import static org.junit.assert.*; import org.junit.test; public Euro(double awert){ wert = awert; public Double getwertindm(){ return wert*2; public class EuroTest public void umrechnungindm(){ Euro euro = new Euro(5.); assertequals(new Double(9.775), euro.getwertindm()); Testergebnis 15

16 Ein Test gelingt Programmklasse public class Euro { private double wert; Testklasse import static org.junit.assert.*; import org.junit.test; public Euro(double awert){ wert = awert; public Double getwertindm(){ return wert*1.955; public class EuroTest public void umrechnungindm(){ Euro euro = new Euro(5.); assertequals(new Double(9.775), euro.getwertindm()); Testergebnis 16

17 Ein Test ist fehlerhaft Programmklasse public class Euro { private double wert; Testklasse import static org.junit.assert.*; import org.junit.test; public Euro(double awert){ wert = awert; public Double getwertindm(){ return wert*1.955; public class EuroTest public void umrechnungindm(){ Euro euro = null; assertequals(new Double(9.775), euro.getwertindm()); Testergebnis 17

18 Neues in JUnit4 Quelle: 18

19 Knackpunkt der Testgetriebenen Entwicklung Zunächst: Was war zuerst da...das Ei oder das Huhn? Herkömmliches Vorgehen: Erst Code schreiben, dann testen Testgetriebenes Vorgehen: Erst testen, dann Code schreiben! 19

20 Die 3 Direktiven (nach Frank Westphal) 1. Motivieren Sie jede Änderung des Programmverhaltens durch einen automatisierten Test. 2. Bringen Sie Ihren Code immer in die Einfache Form. 3. Integrieren Sie Ihren Code so häufig wie nötig. 20

21 Die erste Direktive im Einzelnen Motivieren Sie jede Änderung des Programmverhaltens durch einen automatisierten Test. Ein wenig Testen, ein wenig Programmieren Test programmieren Test schlägt fehl Programm anpassen Test gelingt Nur EIN offener Test pro Schritt Entwicklung erfolgt in kleinen Schritten Rückschritt für den Fortschritt Neue Tests beeinflussen bestehende Tests Features testen, statt Methoden Ein neuer Testfall prüft möglichst das Zusammenspiel von Objekten, nicht deren Methoden 21

22 Die zweite Direktive im Einzelnen Bringen Sie Ihren Code immer in die Einfache Form. In der einfachsten Form anfangen Es wird nicht mehr programmiert, als der Test erfordert Methoden nach und nach erweitern schlechten Geruch entwickeln lassen Code und Struktur anpassen schlechten Geruch entfernen Keine Angst vor Änderungen Evolutionäres Design Die Struktur entwickelt sich Funktionalität ist stets gegeben Stichwort: Refactoring 22

23 Die dritte Direktive im Überblick Integrieren Sie Ihren Code so häufig wie nötig. Einsatz von Versionsverwaltung CVS, Subversion, etc. Häufige Integration Jedes neue Feature wird eingecheckt Funktionalität vorausgesetzt Funktionalität wird durch Tests definiert Solange alle Tests gelingen, ist volle Funktionalität der Software gewährleistet Tests müssen reale Bedingungen optimal abbilden, ggf. erweitert werden 23