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 Die Klassenbibliothek
14 Einführung in die nebenläufige Programmierung
15 Einführung in Datenstrukturen und Algorithmen
16 Einführung in grafische Oberflächen
17 Einführung in Dateien und Datenströme
18 Einführung ins Datenbankmanagement mit JDBC
19 Einführung in <XML>
20 Testen mit JUnit
21 Bits und Bytes und Mathematisches
22 Die Werkzeuge des JDK
A Java SE Paketübersicht
Stichwortverzeichnis

Download:
- Beispielprogramme, ca. 20,0 MB
- Übungsaufgaben, ca. 1,8 MB
- Musterlösungen, ca. 0,8 MB

Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenbloom
Das umfassende Handbuch
Buch: Java ist auch eine Insel

Java ist auch eine Insel
Rheinwerk Computing
1306 Seiten, gebunden, 11. Auflage
49,90 Euro, ISBN 978-3-8362-2873-2
Pfeil 20 Testen mit JUnit
Pfeil 20.1 Softwaretests
Pfeil 20.1.1 Vorgehen bei Schreiben von Testfällen
Pfeil 20.2 Das Test-Framework JUnit
Pfeil 20.2.1 Test-Driven-Development und Test-First
Pfeil 20.2.2 Testen, implementieren, testen, implementieren, testen, freuen
Pfeil 20.2.3 JUnit-Tests ausführen
Pfeil 20.2.4 assertXXX(…)-Methoden der Klasse Assert
Pfeil 20.2.5 Matcher-Objekte und Hamcrest
Pfeil 20.2.6 Exceptions testen
Pfeil 20.2.7 Tests ignorieren und Grenzen für Ausführungszeiten festlegen
Pfeil 20.2.8 Mit Methoden der Assume-Klasse Tests abbrechen
Pfeil 20.3 Wie gutes Design das Testen ermöglicht
Pfeil 20.4 Aufbau größerer Testfälle
Pfeil 20.4.1 Fixtures
Pfeil 20.4.2 Sammlungen von Testklassen und Klassenorganisation
Pfeil 20.5 Dummy, Fake, Stub und Mock
Pfeil 20.6 JUnit-Erweiterungen, Testzusätze
Pfeil 20.7 Zum Weiterlesen
 
Zum Seitenanfang

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

 
Zum Seitenanfang

20.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 20.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, das 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

20.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 visuell getrennt sind. Der Vorteil von Klassen 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 Spiegel-Paket 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 20.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.

Ü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 20.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.

 


Ihr Kommentar

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

>> Zum Feedback-Formular
<< zurück
 Zum Katalog
Zum Katalog: Java ist auch eine Insel Java ist auch eine Insel
Jetzt bestellen

 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Java SE 8 Standard-Bibliothek
Java SE 8 Standard-Bibliothek


Zum Katalog: Professionell entwickeln mit Java EE 7
Professionell entwickeln mit Java EE 7


Zum Katalog: Schrödinger programmiert Java
Schrödinger programmiert Java


Zum Katalog: Einführung in Java
Einführung in Java


Zum Katalog: Programmieren lernen mit Java
Programmieren lernen mit Java


Zum Katalog: Apps entwickeln für Android 5
Apps entwickeln für Android 5


Zum Katalog: Apps entwickeln mit Android Studio
Apps entwickeln mit Android Studio


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2016
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.

 
Nutzungsbestimmungen | Datenschutz | Impressum

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