{"id":560,"date":"2010-04-15T11:31:46","date_gmt":"2010-04-15T09:31:46","guid":{"rendered":"http:\/\/www.tutego.de\/blog\/javainsel\/2010\/04\/junit-4-tutorial-java-tests-mit-junit\/"},"modified":"2015-01-19T13:49:26","modified_gmt":"2015-01-19T11:49:26","slug":"junit-4-tutorial-java-tests-mit-junit","status":"publish","type":"post","link":"https:\/\/www.tutego.de\/blog\/javainsel\/2010\/04\/junit-4-tutorial-java-tests-mit-junit\/","title":{"rendered":"JUnit 4 Tutorial, Java-Tests mit JUnit"},"content":{"rendered":"

Hinweis! Eine aktuelle Version des Abschnittes gibt es im Buch „Java ist auch eine Insel. Einf\u00fchrung, Ausbildung, Praxis“, dem 1. Inselbuch. (War f\u00fcr den 2. Band vorgesehen, musste wegen der F\u00fclle des 2. Buchs kurzerhand in den 1. Band geschoben werden. Sorry f\u00fcr Irritationen!)<\/strong><\/p>\n

1.1 Softwaretests<\/h3>\n

Um m\u00f6glichst viel Vertrauen in die eigene Codebasis zu bekommen, bieten sich Softwaretests an. Tests sind kleine Programme, die ohne Benutzerkontrolle automatisch \u00fcber die Quellcodebasis laufen und anhand von Regeln zeigen, dass gew\u00fcnschte Teile sich so verhalten wie gew\u00fcnscht. (Die Abwesenheit von Fehlern kann eine Software nat\u00fcrlich nicht zeigen, aber immer zeigt ein Testfall, dass das Programm die Vorgaben aus der Spezifikation erf\u00fcllt.)<\/p>\n

Obwohl Softwaretests extrem wichtig sind, sind sie unter Softwareentwicklern nicht unbedingt popul\u00e4r. Das liegt unter anderem daran, dass sie nat\u00fcrlich etwas Zeit kosten, die neben der tats\u00e4chlichen Entwicklung aufgewendet werden muss. Wenn dann die eigentliche Software ge\u00e4ndert wird, m\u00fcssen auch die Testf\u00e4lle oftmals mit angefasst werden, so dass es gleich zwei Baustellen gibt. Und da Entwickler eigentlich immer gestern das Feature fertig stellen sollten, fallen die Testes gerne unter den Tisch. Ein weiterer Grund ist, dass einige Entwickler sich f\u00fcr unfehlbare Codierungsg\u00f6tter halten, die jeden Programmcode (nach ein paar Stunden debuggen) f\u00fcr absolut korrekt, performant und wohl duftend halten.<\/p>\n

Wie l\u00e4sst sich diese skeptische Gruppe nun \u00fcberzeugen, doch Tests zu schreiben? Ein gro\u00dfer Vorteil von automatisierten Tests ist die Eigenschaft, dass bei gro\u00dfen \u00c4nderungen der Quellcodebasis (Refactoring) die Testf\u00e4lle automatisch sagen, ob alles korrekt ver\u00e4ndert wurde. Denn wenn nach dem Refactoring, etwa einer Performance-Optimierung, die Tests einen Fehler melden, ist wohl etwas kaputt-optimiert worden. Da Software einer permanenten \u00c4nderung unterliegt und nie fertig ist, sollte das Argument eigentlich schon ausreichen, denn wenn eine Software eine gewisse Gr\u00f6\u00dfe erreicht hat, ist nicht absehbar, welche Auswirklungen \u00c4nderungen an der Quellcodebasis nach sich ziehen. Dazu kommt ein weiterer Grund, sich mit Tests zu besch\u00e4ftigen. Es ist der positive Nebeneffekt, dass die erzeugte Software vom Design deutlich besser ist, denn testbare Software zu schreiben ist knifflig, f\u00fchrt aber fast zwangsl\u00e4ufig zum besseren Design. Und ein besseres Design ist immer erstrebenswert, denn das erh\u00f6ht die Verst\u00e4ndlichkeit und erleichtert die sp\u00e4tere Anpassung der Software.<\/p>\n

1.1.1 Vorgehen bei Schreiben von Testf\u00e4llen<\/h5>\n

Die Fokussierung bei Softwaretests liegt auf zwei Attributen: automatisch und wiederholbar. Dazu ist eine Bibliothek n\u00f6tig, die zwei Dinge unterst\u00fctzen muss.<\/p>\n

\u00b7 Testf\u00e4lle sehen immer gleich aus und bestehen aus drei Schritten. Zun\u00e4chst wird ein Szenario aufgebaut, dann die zu testende Methode oder Methodenkombination aufgerufen und zum Schluss mit der spezifischen API vom Testframework geschaut, ob das ausgef\u00fchrte Programm genau das gew\u00fcnschte Verhalten gebracht hat. Das \u00dcbernehmen eine Art \u201estimmt-es-dass\u201c-Methoden, die den gew\u00fcnschten Zustand mit dem tats\u00e4chlichen Abgleichen und beim Konflikt eine Ausnahme ausl\u00f6sen.<\/p>\n

\u00b7 Das Testframework muss die Tests laufen lassen und im Fehlerfall eine Meldung geben; der Teil nennt sich Test-Runner<\/em>.<\/p>\n

Wir werden uns im Folgenden auf sogenannte Unit-Tests<\/em> beschr\u00e4nken. Das sind Tests, die einzelne Bausteine (engl. units) testen. Daneben gibt es andere Tests, wie Lasttests, Performance-Tests oder Integrationstests, die aber im Folgenden keine gro\u00dfe Rolle spielen.<\/p>\n

<\/p>\n

1.2 Das Testframework JUnit<\/h4>\n

Sun definiert kein allgemeines Standardframework zur Definition von Unit-Testf\u00e4llen, noch bietet es eine Ablaufumgebung f\u00fcr Testf\u00e4lle. Diese L\u00fccke f\u00fcllen Testframeworks, wobei die popul\u00e4rsten im Java-Bereich das freie quelloffene JUnit<\/em> (http:\/\/www.junit.org\/<\/em>) und (mit Abstand) TestNG<\/em> (http:\/\/testng.org\/<\/em>) sind. Im Folgenden wollen wir uns auf JUnit konzentrieren, ein Framework, welches von Kent Beck und Erich Gamma entwickelt wurde. Um die aktuellste Version von JUnit im Klassenpfad zu haben (IDEs tendieren zu \u00e4lteren Versionen, auch wenn sich JUnit nicht in Lichtgeschwindigkeit entwickelt). Dazu ist von der Download-Seite der JUnit-Homepage, die auf http:\/\/sourceforge.net\/projects\/junit\/files\/junit\/<\/em> weiterleitet, das entsprechende Jar-Archiv zu laden, etwa junit-dep-4.7.jar<\/em> (junit-4.7.jar<\/em> sollte es f\u00fcr das sp\u00e4tere Hamcrest nicht sein, funktioniert aber sonst), und im Klassenpfad aufzunehmen.<\/p>\n

Die Standard-IDEs Eclipse, NetBeans, IntelliJ bringen JUnit gleich mit und bieten Wizards zum einfachen Erstellen von Testf\u00e4llen aus vorhandenen Klassen an. \u00dcber Tastendruck lassen sich Testf\u00e4lle abarbeiten und ein farbiger Balken zeigt direkt an, ob wir unsere Arbeit gut gemacht haben.<\/p>\n

1.2.1 Test-Driven-Development und Test-First<\/h5>\n

Unser JUnit-Beispiel wollen wir nach einem ganz speziellen Ansatz entwickeln, welches sich Test-First<\/em> nennt. Dabei wird der Testfall noch vor der eigentlichen Implementierung geschrieben. Die Reihenfolge mit dem Test-First-Ansatz sieht (etwas erweitert) so aus:<\/p>\n

    \n
  1. \u00dcberlege, welche Klasse und Methode geschrieben werden soll. Lege Quellcode f\u00fcr die Klasse und Variablen\/Methoden\/Konstruktoren an, sodass sich die Compilationsheit \u00fcbersetzen l\u00e4sst.<\/li>\n
  2. Schreibe die API-Dokumentation f\u00fcr die Methoden\/Konstruktoren und \u00fcberlege, welche Parameter, R\u00fcckgaben, Ausnahmen n\u00f6tig sind.<\/li>\n
  3. Teste die API an einem Beispiel, ob sich die Klasse mit Eigenschaften \u201enat\u00fcrlich\u201c anf\u00fchlt. Falls n\u00f6tig wechsele zu Punkt 1 und passe die Eigenschaften an.<\/li>\n
  4. Implementiere eine Testklasse.<\/li>\n
  5. Implementiere die Logik des eigentlichen Programms.<\/li>\n
  6. Gibt es durch die Implementierung neue Dinge, die ein Testfall testen sollte? Wenn ja, erweitere den Testfall.<\/li>\n
  7. F\u00fchre die Tests aus und wiederhole Schritt 5 bis alles fehlerfrei l\u00e4uft.<\/li>\n<\/ol>\n

    Test-Driven-Development hat den gro\u00dfen Vorteil, \u00fcberschnelle Entwickler, die ohne gro\u00df zu denken zur Tastatur greifen, dann implementieren und nach 20 Minuten wieder alles \u00e4ndern, zum Nachdenken zwingt. Gro\u00dfe \u00c4nderungen kosten Zeit und somit Geld und Test-First verringert die Notwendigkeit sp\u00e4terer \u00c4nderungen. Denn wenn Entwickler Zeit in die API-Dokumentation investieren und Testf\u00e4lle schreiben, dann haben sie eine sehr gute Vorstellung \u00fcber die Arbeitsweise der Klasse und gro\u00dfe \u00c4nderungen sind seltener.<\/p>\n

    Der Test-First-Ansatz ist eine Anwendung von Test-Driven-Development (TDD)<\/em>. Hier geht es darum, die Testbarkeit gleich als Ziel bei der Softwareentwicklung zu definieren. Hieran krankten fr\u00fchere Entwicklungsmodelle, etwa das wohlbekannte Wasserfallmodell, welches Testen an das Ende nach Analyse, Design und Implementierung stellte. Die Konsequenz dieser Reihenfolge war oft ein gro\u00dfer Klumpen von Programmcode der unm\u00f6glich zu testen war. Mit TDD soll das nicht mehr passieren. Heutzutage sollten Entwickler sich bei jeder Architektur, jedem Design und der Klasse gleich zu Beginn \u00fcberlegen, wie das Ergebnis zu testen ist. Untersuchungen zeigen: Mit TDD ist das Design signifikant besser.<\/p>\n

    Zur Frage wann Tests durchgef\u00fchrt werden sollen l\u00e4sst sich nur eins festhalten: So oft wie m\u00f6glich. Denn je eher ein Test durch eine falsche Programm\u00e4nderung fehlschl\u00e4gt, desto eher kann der Fehler behoben werden. Gute Zeitpunkte sind daher vor und hinter gr\u00f6\u00dferen Design\u00e4nderungen und auf jeden Fall vor dem Einpflegen in die Versionsverwaltung. Im modernen Entwicklungsprozess gibt es einen Rechner, auf dem eine Software zur kontinuierlichen Integration l\u00e4uft (engl. Continuous Integration). Diese Systeme integrieren einen Build-Server, der die Quellen automatisch aus einer Versionsverwaltung auscheckt, compiliert und dann Testf\u00e4lle und weitere Metriken laufen l\u00e4sst. Diese Software \u00fcbernimmt dann einen Integrationstest<\/em>, da hier alle Module der Software zu einer Gesamtheit zusammengebaut werden und so Probleme aufgezeigt werden, die sich vielleicht bei isolierten Tests auf den Entwicklermaschinen nicht zeigen.<\/p>\n

    1.2.2 Testen, implementieren, testen, implementieren, testen, freuen<\/h5>\n

    Bisher bietet Java keine einfache Funktion, um Strings umzudrehen. Unser erstes JUnit-Beispiel soll daher um eine Klasse StringUtils gestrickt werden, die eine statische Methode reverse() anbietet. Nach dem TDD-Ansatz implementieren wir eine Klasse, die korrekt \u00fcbersetzt werden kann, aber bisher ohne Funktionalit\u00e4t ist. (Auf die API-Dokumentation verzichtet das Beispiel.)<\/p>\n

    com\/tutego\/insel\/junit\/util\/StringUtils.java, StringUtils<\/p>\n

    public class StringUtils\r\n{\r\n public static String reverse( String string )\r\n<\/strong> {\r\n<\/strong>  return null;\r\n<\/strong> }\r\n<\/strong>}<\/pre>\n
    Gegen diese eigene API l\u00e4sst sich nun der Testfall schreiben. Spontan f\u00e4llt uns ein, dass ein Leerstring umgedreht nat\u00fcrlich auch ein Leerstring ergibt und die Zeichenkette \u201eabc\u201c umgedreht \u201ecba\u201c ergibt. Ziel ist es, eine m\u00f6glichst gute Abdeckung<\/em> aller F\u00e4lle zu bekommen. Wenn wir Fallunterscheidungen im Programmcode vermuten sollten wir versuchen so viele Testf\u00e4lle zu finden, sodass alle diese Fallunterscheidungen abgelaufen werden. Interessant sind beim Eingeben immer Sonderf\u00e4lle bzw. Grenzen von Wertebereichen. (Unsere Methode gibt da nicht viel her, aber wenn wir etwa eine Substring-Funktion haben, lassen sich schnell viele Methoden\u00fcbergaben finden, die interessant sind.)<\/p>\n
    com\/tutego\/insel\/junit\/util\/StringUtilsTest.java<\/p>\n
    package com.tutego.insel.junit.util;\r\nimport static org.junit.Assert.*;\r\n<\/strong>import org.junit.Test;\r\npublic class StringUtilsTest\r\n{\r\n @Test\r\n<\/strong> public void testReverse()\r\n<\/strong> {\r\n  assertEquals( \"\", StringUtils.reverse( \"\" ) );\r\n<\/strong>  assertEquals( \"cba\", StringUtils.reverse( \"abc\" ) );\r\n<\/strong> }\r\n}<\/pre>\n
    Die Klasse zeigt vier Besonderheiten.<\/p>\n
      \n
    1. Die Methode, die sich einzelne Szenarien vornehmen und Klassen\/Methoden testen, tragen die Annotation @Test.<\/li>\n
    2. Eine \u00fcbliche Namenskonvention (obwohl nicht zwingend n\u00f6tig) ist, dass die Methode, die den Test enth\u00e4lt mit dem Pr\u00e4fix \u201etest\u201c beginnt und mit dem Namen der Methode endet, die sie testet. Da in unserem Fall die Methode reverse() getestet wird, hei\u00dft die Testmethode dementsprechend \u201etestReverse\u201c. Eine testXXX()-Methode liefert nie eine R\u00fcckgabe. Testmethoden k\u00f6nnen auch ganze Szenarien testen, die nicht unbedingt an einer Methode festzumachen sind, aber hier testest testReverse() nur die reverse()-Methode.<\/li>\n
    3. JUnit bietet eine Reihe von assertXXX()-Methoden, die den erwarteten Zustand mit dem Ist-Zustand vergleichen; gibt es Abweichungen folgt eine Ausnahme. assertEquals() nimmt einen equals()-Vergleich der beiden Objekte vor. Wenn demnach StringUtils.reverse(„“) die leere Zeichenkette „“ liefert, ist alles in Ordnung und der Test wird fortgesetzt.<\/li>\n
    4. Der statische Import aller statischen Eigenschaften der Klasse org.junit.Assert k\u00fcrzt die Schreibweise ab, sodass im Programm statt Assert.assertEquals() nur assertEquals() geschrieben werden kann.<\/li>\n<\/ol>\n
      1.2.3 JUnit-Tests ausf\u00fchren<\/h5>\n
      In einer Entwicklungsumgebung l\u00e4sst sich die Testausf\u00fchrung leicht ablaufen. Eclipse zeigt zum Beispiel die Ergebnisse in der JUnit-View an und bietet mit einem gr\u00fcnen bzw. roten Balken direktes visuelles Feedback.<\/p>\n
      Nat\u00fcrlich lassen sich die Tests auch von Kommandozeile ausf\u00fchren, obwohl das selten ist, denn in der Regel werden die Tests im Zuge eines Build-Prozess \u2013 den etwa Ant steuert \u2013 angesto\u00dfen. Wer das dennoch \u00fcber die Kommandozeile machen m\u00f6chte, schreibt:<\/p>\n
      com\/tutego\/insel\/junit\/RunTest.java, main()<\/p>\n
      JUnitCore.main( StringUtilsTest.class.getName() );<\/pre>\n
      1.2.4 assertXXX()-Methoden der Klasse Assert<\/h5>\n
      Assert ist die Klasse mit den assertXXX()-Methoden, die immer dann einen AssertionError ausl\u00f6sen, wenn ein aktueller Wert nicht so wie der gew\u00fcnschte war. Der JUnit-Runner registriert alle AssertionError und speichert sie f\u00fcr die Statistik. Bis auf drei Ausnahmen beginnen alle Methoden der Klasse Assert mit dem Pr\u00e4fix \u201eassert\u201c \u2013 zwei andere hei\u00dfen fail() und eine isArray() \u2013 und alle Methoden gibt es einmal mit einer Testmeldung, die beim AssertionError dann erscheint, und einmal ohne, wenn JUnit keine extra Meldung angeben soll.<\/p>\n
      Eigentlich reicht zum Testen die Methode assertTrue(boolean condition) aus. Ist die Bedingung wahr, so ist alles in Ordnung. Wenn nicht, gibt es den AssertionError.<\/p>\n\n\n\n
      org.junit.Assert<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n