Literatur und Web. Komponenten WS 2014/15 Teil 6/JUnit

Transkript

1 Literatur und Web [6-1] Vigenschow, Uwe: Objektorientiertes Testen und Testautomatisierung in der Praxis. dpunkt, 2005 [6-2] Westphal, Frank: Testgetriebene Entwicklung mit JUnit & FIT. dpunkt, 2006 [6-3] Link, Johannes: Softwaretests mit JUnit. 2. Auflage, dpunkt, 2005 [6-4] Tamm, Michael: JUnit-Profiwissen. dpunkt, 2013 [6-5] Ullenboom, C.: Java 7 - Mehr als eine Insel: Das Handbuch zu den Java SE-Bibliotheken, Gallileo Computing,

2 Übersicht Das Problem: Zeitpunkte zum Testen Arbeiten mit Assertions Arbeiten mit Junit Zusammenarbeit mit Maven Testfälle und Testsuites Integration in netbeans 3 Das Problem Klassische Vorgehensweise Tests werden zuerst von den Entwicklern durchgeführt. Dann folgen Tests im Rahmen der Integration. Dann Tests bei der Abnahme. Anschließend wird alles, was mit Tests zu tun hat, aus dem Code entfernt. Alle diese Tests sind später bei Weiterentwicklungen nicht mehr verfügbar, so dass sie manuell wiederholt werden müssen. Sie sind auch nicht mit dem Code verbunden. Tests können auch nicht zum Vertragsgegenstand gemacht werden. 4

3 Eine Lösung Der Code zur Prüfung ist und bleibt Bestandteil des Codes. Es wird ein Mechanismus zum automatisierten Test benutzt, der jederzeit, auch nach Auslieferung, benutzt werden kann. Verfahren bzw. Lösungen: Assertion JUnit 5 Assertions I Assertion = Zusicherung = Bedingung an Variablenwerte, die im Falle der Korrektheit, immer wahr sein muss Beispiele: if (a < 0) { Assertion: a < 0... else { Assertion: a >= Assertion a==??, b==?? a= 10; Assertion a==10, b==?? a= a+b; Assertion a==??, b==??... (beide Beispiele in Freistilnotation) 6

4 Assertions II Die Semantik jedes Statements sowie jedes Kontrollkonstrukts lässt sich als Transformation von Zusicherungen beschreiben. Durch die Verkettung von Statements - meistens sequentiell, aber auch parallel - lässt sich ein Programm als ein komplexer prädikatenlogischer Ausdruck beschreiben. Diese Beschreibung kann aufgrund einer Analyse ohne Ablauf des Programms erstellt werden. Sie kann auch sich nur auf ausgeführte Bereiche beziehen; dies wird dann symbolische Ausführung genannt. 7 Benutzung zum Testen An strategisch wichtigen Punkten werden Assertions eingefügt, die zu einer Fehlermeldung führen, wenn sie nicht zutreffen. Typische Punkte sind: Direkt zum Beginn einer Methode, um Parameter auf Korrektheit zu prüfen Direkt vor dem Ende einer Methode, um die Korrektheit des Resultates zu prüfen Innerhalb der Methode, wo problematische Abschnitte durchlaufen wurden Problematisch sind alle Abschnitte, wo die Bedeutung nicht ganz klar ist, z.b. nach Aufruf schlecht getesteter oder unverstandener Methoden. Über eine Compiler-Option kann bzw. in Java muss gesteuert werden, ob die Assertions ausgeführt werden oder nicht. 8

5 Beispiel I public class Assert1 { Assert1() { System.out.println(invers(1.0)); System.out.println(invers(2.0)); System.out.println(invers(10.0)); System.out.println(invers(0.0)); double invers(double arg) { return 1/arg; public static void main(string[] args) { new Assert1(); Infinity 9 Beispiel II public class Assert2 { Assert2() { System.out.println(invers(1.0)); System.out.println(invers(2.0)); System.out.println(invers(10.0)); System.out.println(invers(0.0)); double invers(double arg) { assert arg!= 0.0: "Datt jeht nich!"; return 1/arg; public static void main(string[] args) { new Assert2(); 10

6 Beispiel IV Es wird dann eine Fehlermeldung zusammen mit dem Traceback, d.h. der Angabe der Aufrufstellen der Methoden ausgegeben. 12

7 JUnit 4.11 JUnit ist eine Umgebung zum Testen von kleineren Codeteilen, insbesondere einzelnen Klassen oder kleineren Klassenverbänden. Eine Klasse wird in diesem Sinne Unit genannt. Es wird hier die Version 4.11 behandelt. Die Tests sind bei der Version 3.8 und ab 4.0 syntaktisch anders aufgebaut. JUnit war so erfolgreich, dass diese Idee auf andere Programmiersprachen implementiert wurde, z.b. PHPUnit. 13 Bedingungen an Unit-Tests I Es sollten keine Datenbankzugriffe notwendig sein. Es sollte keine Kommunikation über das Netzwerk notwendig sein. Es sollten keine Veränderungen während der Tests an Dateien vorgenommen werden. Zum Test sollten keine besonderen Konfigurationsdateien editiert werden müssen. Alle Tests müssen in beliebiger Reihenfolge (und auch beliebig häufig) ablauffähig sein. Alle Tests sollten in wenigen Sekunden ablaufen können. Diese Bedingungen sollen dazu führen, dass alle erstellten Tests jederzeit "so nebenbei" ablaufen können. Aber: das ist in der Praxis nicht immer praktikabel. 14

8 Bedingungen an Unit-Tests II Sind diese Bedingungen nicht erfüllt, so handelt es sich nicht um Unit-Tests (und dafür ist JUnit nicht gebaut worden). Aber das sollte niemanden abhalten trotzdem damit Unit-Tests durchzuführen Die Idee Zuerst werden die Testfälle entworfen und implementiert. Diese bestehen aus: einer Umgebung, die vorbereitet werden muss: das Fixture den erwarteten Ergebnissen Die Testfälle müssen sehr einfach sein, damit sie nicht selbst auch getestet werden müssen unabhängig sein, da die Reihenfolge der Tests nur sehr bedingt bestimmt werden kann eine kurze Laufzeit haben Die Testfälle selbst bilden eine Beschreibung der Bedeutung, in gewisser Weise eine "Dokumentation". 16

9 Konsequenzen Klassen bzw. deren Methoden können nicht mehr einfach so konzipiert werden; sie müssen eventuell so umstrukturiert werden, dass sie mit JUnit getestet werden können. Die Tests werden wie die Software mit ausgeliefert. Die Tests können (oder sollten?) auch mit dem Kunden vereinbart werden. Das stößt auf die Schwierigkeit, dass Kunden sich selten mit Unit- Tests befassen, sondern nur mit Abnahmetests, die aber in jedem Fall die oben erwähnten Bedingungen verletzen. Aber: Alles steht und fällt mit der vollständigen, oder wenigstens vernünftigen Auswahl der Testfälle. 17 Beispiel: Zinsklasse Es wird eine Methode, der als 1. Parameter der volle Wert und als 2. Parameter ein Anteil übergeben wird und die als Rückgabewert den entsprechenden Prozentwert zurückliefert, entwickelt. public class Interest { public double computepercent(double whole, double part) { return Double.MAX_VALUE; 18

10 Mit maven zu Fuß I mvn archetype:generate -DgroupId=de.htw_berlin.f4.kbe.junit -DartifactId=percent -Dpackage=de.htw_berlin.f4.kbe -Dversion=1.0-SNAPSHOT -DarchetypeArtifactId=maven-archetype-quickstart <build> <plugins> <plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-jar-plugin</artifactid> <version>2.4</version> <configuration> <archive> <manifest> <mainclass>de.htw_berlin.f4.kbe.percent</mainclass> <addclasspath>true</addclasspath> </manifest> </archive> </configuration> </plugin> Baustein jar-generierung Einsetzen 19 Mit maven zu Fuß II <plugin> <groupid>org.codehaus.mojo</groupid> <artifactid>exec-maven-plugin</artifactid> <version>1.2.1</version> <configuration> <mainclass>de.htw_berlin.f4.kbe.percent</mainclass> </configuration> </plugin> </plugins> </build> Einsetzen Baustein Execute <properties> <project.build.sourceencoding>utf-8</project.build.sourceencoding> </properties 20

11 Mit maven zu Fuß III <dependency> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>4.11</version> <scope>test</scope> </dependency> Baustein JUnit Version 4.11 benutzen package de.htw_berlin.f4.kbe; public class Percent { Pseudo-Programm public static void main(string[] args) { Interest inter= new Interest(); double per= inter.computepercent(1.0, 2.0); System.out.println("Percent "+per); 21 Mit maven zu Fuß IV package de.htw_berlin.f4.kbe; Zu testende Klasse: Nur der Rahmen public class Interest { public double computepercent(double whole, double part) { return Double.MAX_VALUE; package de.htw_berlin.f4.kbe; import org.junit.test; import static org.junit.assert.*; Testfall, der immer gelingt public class InterestTest { public InterestTest() public void testcomputerpercent() { assertequals(0.0, 0.0, 0.0); 22

12 Auch unter netbeans direkt geht es Hinweis: In diesem Fall benutzen wir netbeans nur als Editor. Maven wird außerhalb innerhalb anderer Ordner benutzt. 24

13 JUnit-Methoden für die Testklassen (Auszug) asserttrue(boolean) assertfalse(boolean) assertequals(expected,actual) assertequals(expected,actual,delta) assertnull(object) assertnotnull(object) assertsame(expected,actual) assertnotsame(expected,actual) fail(string) Prüfung, ob wahr bzw. false ist Vergleich zweier Werte auf Gleichheit mit möglichen Delta Hat die Referenzvariable den Wert Null oder nicht Sind die beiden Objekte identisch oder nicht (Referenzen) Test ist nicht bestanden Mit dem delta-wert kann für float/double-werte ein Intervall angegeben werden. Dies ist aufgrund möglicher Rundungsfehler notwendig. Zur besseren Erläuterung kann ein String als erster Parameter eingeschoben werden. 25 Ein richtiger Testfall I public class InterestTest { Interest value; public InterestTest() public void setup() throws Exception { value= new public void teardown() throws Exception { value= public void testzero() { assertequals(0, value.computepercent(10,100), 0.001); Aufbau der Testumgebung Abbau der Testumgebung Testfall Kleiner Hinweis: der Testfall ist fehlerhaft aber das wissen wir nicht... 26

14 Begriffe Fixture = Umgebung bestehend aus Objekten, die den Kontext des Testens definieren Ein Fixture wird zum Beginn des Tests aufgebaut und am Ende abgebaut. Fixtures verschiedener Tests dürfen sich nicht beeinflussen. Runner = Software, die die Tests durchführt und über das Ergebnis berichtet: Visuell mit einem grünen oder rotem Balken Textuell durch eine Zusammenfassung Es gibt für verschiedene Anwendungsfälle unterschiedliche Runner; sie können sogar selbst geschrieben werden. 27 Ein richtiger Testfall II Das geht natürlich schief. 28

15 Ein richtiger Testfall III package de.htw_berlin.f4.kbe; public class Interest { public double computepercent(double whole, double part) { return whole*100/part; Aus netbeans heraus muss installiert werden, hier per bat-datei: set SRC=D:\bmesser\NetBeansProjects\junit-Percent\src\de\htw_berlin\f4\kbe set DST=D:\temp\percent\src\main\java\de\htw_berlin\f4\kbe xcopy /Y %SRC%\*.java %DST% set SRC=D:\bmesser\NetBeansProjects\junit-Percent\test\de\htw_berlin\f4\kbe set DST=D:\temp\percent\src\test\java\de\htw_berlin\f4\kbe xcopy /Y %SRC%\*.java %DST% pause 29

16 Nun der nächste Testfall public void testzero() { assertequals(0,value.computepercent(0,100), public void testten() { assertequals(0.1,value.computepercent(100,10), 0.001); Ein Test auf 10% - und scheitert, denn: public class Interest { public double computepercent(double whole, double part) { return whole*100/part; Oops ach ja schon wieder war der Test falsch, nun ist er public void testten() { assertequals(10, value.computepercent(100,10), 0.001); 31 Nun der nächste Testfall II Der zweite Test ist nun in Ordnung, aber der erste, der ja vorher lief, nicht. Denn nun gibt es eine Division durch 0. public class Interest { public double computepercent(double whole, double part) { if(whole==0) { return 0; return part*100/whole; Und wieder alles im Lot: 32

17 Nun der nächste Testfall II Aber schlechter Stil! public class Interest { public double computepercent(double whole, double part) { if(whole==0.0) { return 0.0; else { return part*100.0/whole; Warum ist das nun besser?? In jedem Fall ist bei Qualitätsverbesserungen am Code und seien es nur kosmetische Dinge das Testen mit Junit sehr, sehr hilfreich. 33 Nun weitere public void testzero() { assertequals(0, value.computepercent(0,100), public void testten() { assertequals(10,value.computepercent(100,10), public void testvalues() { assertequals(50, value.computepercent(100, 50), 0.001); assertequals(100,value.computepercent(100,100), 0.001); assertequals(50, value.computepercent(200,100), 0.001); Es gibt die Empfehlung, immer nur einen Testfall pro Testroutine zu testen, um Fehler besser einkreisen zu können. Bei Klassen mit inneren Zuständen muss dies auch sein, da sich dann die Tests gegenseitig beeinflussen können. 34

18 Jetzt die negativen public void testnegative() { assertequals(10, value.computepercent(-100,10), 0.001); assertequals(10, value.computepercent(100,-10), 0.001); Und: Fehler! Und wir verbessern sofort: public double computepercent(double whole, double part) { double abswhole= Math.abs(whole); double abspart = Math.abs(part); if(abswhole==0.0) { return 0.0; else { return abspart*100.0/abswhole; 35 public void testextrem() { assertequals(0, value.computepercent(0,0), 0.001); assertequals(0, value.computepercent(double.max_value,1), 0.001); assertequals(0, value.computepercent(double.max_value,1), 0.0); assertequals(0, value.computepercent(double.max_value,double.min_value),0.001); assertequals(100,value.computepercent(double.max_value,double.max_value),0.001); Die beiden roten Tests scheitern. Dies zu reparieren, ist (vielleicht) eine Hausaufgabe. 36

19 Wahl der Testfälle Alle Sonderfälle Alle gerade noch erlaubten Extremfälle Leichte Abweichungen der Extremfälle ins Falsche (falls die Klasse dies prüfen soll) Ein oder zwei Durchschnittsfälle 37 Schema für das Testen einer Klasse I import org.junit.after; import org.junit.afterclass; import org.junit.before; import org.junit.beforeclass; import org.junit.test; import static org.junit.assert.*; public class Name { public Name() public static void setupclass() public static void teardownclass() public void setup() public void teardown() public void testcase() { fail("test uncompleted"); 38

20 Schema für das Testen einer Klasse @Test Bedeutung Routine wird einmal zum Beginn des Tests der Klasse ausgeführt. Routine wird einmal nach dem Test der Klasse ausgeführt. Routine wird jedes Mal vor einem Test einmal ausgeführt. Routine wird jedes Mal nach einem Test einmal ausgeführt. Routine realisiert einen Test. 39 Ein zweites Beispiel Reziproke Werte I public class Invertation { double invers(double arg) { //assert arg!= 0.0: "Datt jeht nich!"; return 1.0/arg; public class InvertationTest { Invertation value; public InvertationTest() public void setup() { value= new public void teardown() { value= public void testvalues() { assertequals(0.01, value.invers(100), 0.001); So sieht die Klasse (von oben) aus. Dieser Test läuft! 40

21 Ein zweites Beispiel Reziproke Werte public void testvalues() { assertequals(0.01, value.invers(100), 0.001); assertequals(0.1, value.invers(10), 0.001); assertequals(1, value.invers(1), public void testnegative() { assertequals(-0.01, value.invers(-100), 0.001); assertequals(-0.1, value.invers(-10), 0.001); assertequals(-1, value.invers(-1), public void testzero() { assertequals(0, value.invers(0), 0.001); Dieser Test läuft! Dieser Test läuft! Dieser Test läuft nicht! 41 Ein zweites Beispiel Reziproke Werte II public class Invertation { double invers(double arg) { if(arg!= 0.0) { return 1.0/arg; else { throw new IllegalArgumentException(); Nun wird eine Exception geworfen, die durch den Aufrufer nicht behandelt werden muss. 42

22 Ein zweites Beispiel Reziproke Werte public void testzero() { try { double val= value.invers(0); fail("illegalargumentexception expected"); catch (IllegalArgumentException args) { Erwartete Exception Erläuternde Meldung So sieht der dazu gehörende Testfall aus. 43 Suites Zusammenfassen mehrerer Testklassen I public class Invertation1Test public void testvalues() { System.out.println("Invertation1Test"); assertequals(0.01, value.invers(100), 0.001); assertequals(0.1, value.invers(10), 0.001); assertequals(1, value.invers(1), 0.001); public class Invertation2Test public void testnegative() { System.out.println("Invertation2Test"); assertequals(-0.01, value.invers(-100), 0.001); assertequals(-0.1, value.invers(-10), 0.001); assertequals(-1, value.invers(-1), 0.001); 44

23 Suites Zusammenfassen mehrerer Testklassen III public class Invertation3Test public void testzero() { System.out.println("Invertation3Test"); try { double val= value.invers(0); fail("illegalargumentexception expected"); catch (IllegalArgumentException args) { In diesem Beispiel wurde die einzelne Klasse auf drei Klassen aufgeteilt. In der Praxis testet eine Testklasse eine Klasse, so dass bei einer solchen Konstruktion mehrere Klassen einzeln getestet werden. 45 Suites Zusammenfassen mehrerer Testklassen IV package de.htw_berlin.f4.kbe; import org.junit.runners.suite; Invertation1Test.class, Invertation2Test.class, Invertation3Test.class ) public class InvertationSuite { Es ist ein anderer Runner erforderlich es gibt viele(!). Eine Suite wird über eine Annotation definiert. Eine Liste von Klassendeskriptoren bildet die Suite Die eigentliche Klasse dient nur der Form, die Tests laufen über die Annotations 46

24 Suites Zusammenfassen mehrerer Testklassen V Beispiellauf innerhalb von netbeans (ohne Maven) 47 Messung der Testabdeckung mit cobertura I <plugin> <groupid>org.codehaus.mojo</groupid> <artifactid>cobertura-maven-plugin</artifactid> <version>2.6</version> <configuration> <formats> <format>html</format> <format>xml</format> </formats> </configuration> </plugin> Aufruf mvn cobertura:cobertura Ein neues Plugin muss dazu im build-bereich deklariert werden. Siehe: 48

25 Messung der Testabdeckung mit cobertura II 49 Messung der Testabdeckung mit cobertura III Im target-ordner unter site sind die HTML-Dateien und die XML-Datei zur automatischen Auswertung. 50

26 Maven in netbeans I Maven-Projekt auswählen (nach Installation des Plugins) Dann die Koordinaten eingeben 51 Maven in netbeans II Bei den Dependency Junit mit Version 4.11 angeben sowie die Klassen definieren, einschließlich der Testklassen (letztere über den Generator) Die POM-Datei kann auch direkt editiert werden. 52

27 Maven in netbeans III Mit der Maus (rechte Taste) über das Projekt als Ziel z.b. test angeben dann läuft mvn test ab. Im Console-Fenster erscheinen die (vielen) Maven-Meldungen. 53 Nach dieser Anstrengung etwas Entspannung... 54