Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger. 
Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Objektorientierte Beziehungsfragen
7 Ausnahmen müssen sein
8 Äußere.innere Klassen
9 Besondere Typen der Java SE
10 Generics<T>
11 Lambda-Ausdrücke und funktionale Programmierung
12 Architektur, Design und angewandte Objektorientierung
13 Komponenten, JavaBeans und Module
14 Die Klassenbibliothek
15 Einführung in die nebenläufige Programmierung
16 Einführung in Datenstrukturen und Algorithmen
17 Einführung in grafische Oberflächen
18 Einführung in Dateien und Datenströme
19 Einführung ins Datenbankmanagement mit JDBC
20 Einführung in <XML>
21 Testen mit JUnit
22 Bits und Bytes und Mathematisches
23 Die Werkzeuge des JDK
A Java SE-Paketübersicht
Stichwortverzeichnis


Download:

- Beispielprogramme, ca. 35,4 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil 21 Testen mit JUnit
Pfeil 21.1 Softwaretests
Pfeil 21.1.1 Vorgehen beim Schreiben von Testfällen
Pfeil 21.2 Das Test-Framework JUnit
Pfeil 21.2.1 Test-Driven Development und Test-First
Pfeil 21.2.2 Testen, implementieren, testen, implementieren, testen, freuen
Pfeil 21.2.3 JUnit-Tests ausführen
Pfeil 21.2.4 assertXXX(…)-Methoden der Klasse Assert
Pfeil 21.2.5 Matcher-Objekte und Hamcrest
Pfeil 21.2.6 Exceptions testen
Pfeil 21.2.7 Tests ignorieren und Grenzen für Ausführungszeiten festlegen
Pfeil 21.2.8 Mit Methoden der Assume-Klasse Tests abbrechen
Pfeil 21.3 Wie gutes Design das Testen ermöglicht
Pfeil 21.4 Aufbau größerer Testfälle
Pfeil 21.4.1 Fixtures
Pfeil 21.4.2 Sammlungen von Testklassen und Klassenorganisation
Pfeil 21.5 Dummy, Fake, Stub und Mock
Pfeil 21.6 JUnit-Erweiterungen, Testzusätze
Pfeil 21.7 Zum Weiterlesen
 

Zum Seitenanfang

21.4Aufbau größerer Testfälle Zur vorigen ÜberschriftZur nächsten Überschrift

Bisher haben wir uns mit abgeschlossenen Testfällen beschäftigt und weniger darüber nachgedacht, wie eine größere Anzahl Tests organisiert werden.

 

Zum Seitenanfang

21.4.1Fixtures Zur vorigen ÜberschriftZur nächsten Überschrift

Eine wichtige Eigenschaft von Tests ist, dass sie voneinander unabhängig sind. Die Annahme, dass ein erster Test zum Beispiel ein paar Testdaten anlegt, auf die dann der zweite Test zurückgreifen kann, ist falsch. Aus dieser Tatsache muss die Konsequenz gezogen werden, dass jede einzelne Testmethode davon ausgehen muss, die erste Testmethode zu sein, und somit ihren Initialzustand selbst herstellen muss. Es wäre aber unnötige Quellcodeduplizierung, wenn jede Testmethode nun diesen Startzustand selbst aufbauen würde. Dieser Anfangszustand heißt Fixture (zu Deutsch etwa »festes Inventar«), und JUnit bietet hier vier Annotationen. Wie sie wirken, zeigt folgendes Beispiel:

Listing 21.10com/tutego/insel/junit/util/FixtureDemoTest.java, FixtureDemoTest

public class FixtureDemoTest

{

@BeforeClass public static void beforeClass()

{

System.out.println( "@BeforeClass" );

}

@AfterClass public static void afterClass()

{

System.out.println( "@AfterClass" );

}

@Before public void setUp()

{

System.out.println( "@Before" );

}

@After public void tearDown()

{

System.out.println( "@After" );

}

@Test public void test1()

{

System.out.println( "test 1" );

}

@Test public void test2()

{

System.out.println( "test 2" );

}

}

Die Annotationen beziehen sich auf zwei Anwendungsfälle:

  • @BeforeClass, @AfterClass: Annotiert statische Methoden, die einmal aufgerufen werden, wenn die Klasse für den Test initialisiert wird bzw. wenn alle Tests für die Klasse abgeschlossen sind.

  • @Before, @After: Annotiert Objektmethoden, die immer vor bzw. nach einer Testmethode aufgerufen werden.

Läuft unser Beispielprogramm, ist die Ausgabe daher wie folgt:

@BeforeClass

@Before

test 1

@After

@Before

test 2

@After

@AfterClass

In die @BeforeClass-Methoden wird üblicherweise das reingesetzt, was teuer im Aufbau ist, etwa eine Datenbankverbindung. Die Ressourcen werden dann in der symmetrischen Methode @AfterClass wieder freigegeben, also zum Beispiel werden Datenbankverbindungen wieder geschlossen. Da nach einem Test keine Artefakte vom Testfall bleiben sollen, führen gute @AfterClass/@After-Methoden sozusagen ein Undo durch.

[zB]Beispiel

Setzt ein System.setProperty(…) »globale« Zustände oder überschreibt es vordefinierte Properties, so ist @BeforeClass ein guter Zeitpunkt, um einen Snapshot zu nehmen und diesen später bei @AfterClass wiederherzustellen:

private static String oldValue;

@BeforeClass public static void beforeClass()

{

oldValue = System.getProperty( "property" );

System.setProperty( "property", "newValue" );

}

@AfterClass public static void afterClass()

{

if ( oldValue != null )

{

System.setProperty( "property", oldValue );

oldValue = null;

}

}
 

Zum Seitenanfang

21.4.2Sammlungen von Testklassen und Klassenorganisation Zur vorigen ÜberschriftZur nächsten Überschrift

Werden die Tests zahlreicher, stellt sich die Frage nach der optimalen Organisation. Als praktikabel hat sich erwiesen, die Testfälle in das gleiche Paket wie die zu testenden Klassen zu setzen, aber den Quellcode physikalisch zu trennen. Entwicklungsumgebungen bieten hierzu Konzepte: So sieht Eclipse unterschiedliche src-Order vor, die zu Klassen im gleichen Klassenpfad führen und dennoch in der IDE physikalisch und visuell getrennt sind. Nach dem Maven-Standard-Verzeichnis-Layout sind das src/main und src/test. Der Vorteil von Typen im gleichen Paket ist, dass oftmals die Paketsichtbarkeit ausreicht und nicht vorher private Eigenschaften nur für Tests öffentlich gemacht werden müssen.

Wenn es nun für jedes Paket ein Spiegelpaket mit den Testklassen gibt, wie werden all diese Testklassen eines Pakets in einem Rutsch ausgeführt? Der Trick besteht im Aufbau einer Test-Suite:

Listing 21.11com/tutego/insel/junit/util/TestPackage.java, TestPackage

@RunWith( Suite.class )

@Suite.SuiteClasses(

{

StringUtilsTest.class, FixtureDemoTest.class

} )

public class PackageTest { }

Die Testklasse ist im Rumpf leer und zählt lediglich über Suite.SuiteClasses die Klassen auf. Soll eine Testklasse nicht ausgeführt werden, muss sie dort nicht stehen.

Üblicherweise besteht ein Projekt aus mehreren hierarchischen Paketen. Wie ist es dann möglich, das ganze Projekt mit allen Paketen zu testen und nicht nur ein Paket? Hier hilft uns die Tatsache, dass eine Suite selbst eine Art Testfall ist, die bei @Suite.SuiteClasses angegeben werden darf. Das heißt praktisch: In jedem Paket wird eine Suite definiert, die alle Testklassen, aber auch die Test-Suite der Unterklassen referenziert. In unserem Beispiel heißt das: Wenn wir in com.tutego.insel.junit.util eine Suite PackageTest hatten, die die beiden Testklassen StringUtilsTest und FixtureDemoTest anspricht, so setzen wir in das übergeordnete Paket com.tutego.insel.junit (ohne util also) ebenfalls eine Suite PackageTest, die dann com.tutego.insel.junit.util.PackageTest referenziert:

Listing 21.12com/tutego/insel/junit/TestPackage.java, TestPackage

@RunWith( Suite.class )

@Suite.SuiteClasses(

{

com.tutego.insel.junit.util.PackageTest.class

} )

public class PackageTest { }

Der eigentliche Test wird demnach oben in einer Haupthierarchie gestartet und läuft dann rekursiv alle Unterpakete ab.

inline In Eclipse reicht es, auf einen Zweig zu gehen und dann im Kontextmenü Run AsJunit Test auszuwählen; das läuft dann alle Tests auch in den Unterpaketen ab. Test-Suites ersetzt dies noch nicht, denn Suites werden außerhalb der IDE ausgeführt.

 


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück

 

 


Copyright © Rheinwerk Verlag GmbH 2017

Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

[Rheinwerk Computing]



Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de