Rheinwerk Computing < openbook >


 
Inhaltsverzeichnis
Materialien
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Arrays und ihre Anwendungen
5 Der Umgang mit Zeichenketten
6 Eigene Klassen schreiben
7 Objektorientierte Beziehungsfragen
8 Ausnahmen müssen sein
9 Geschachtelte Typen
10 Besondere Typen der Java SE
11 Generics<T>
12 Lambda-Ausdrücke und funktionale Programmierung
13 Architektur, Design und angewandte Objektorientierung
14 Java Platform Module System
15 Die Klassenbibliothek
16 Einführung in die nebenläufige Programmierung
17 Einführung in Datenstrukturen und Algorithmen
18 Einführung in grafische Oberflächen
19 Einführung in Dateien und Datenströme
20 Einführung ins Datenbankmanagement mit JDBC
21 Bits und Bytes, Mathematisches und Geld
22 Testen mit JUnit
23 Die Werkzeuge des JDK
A Java SE-Module und Paketübersicht
Stichwortverzeichnis


Download:

- Listings, ca. 2,7 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 22 Testen mit JUnit
Pfeil 22.1 Softwaretests
Pfeil 22.1.1 Vorgehen beim Schreiben von Testfällen
Pfeil 22.2 Das Test-Framework JUnit
Pfeil 22.2.1 Test-Driven Development und Test-First
Pfeil 22.2.2 Testen, implementieren, testen, implementieren, testen, freuen
Pfeil 22.2.3 JUnit-Tests ausführen
Pfeil 22.2.4 assertXXX(…)-Methoden der Klasse Assertions
Pfeil 22.2.5 Exceptions testen
Pfeil 22.2.6 Grenzen für Ausführungszeiten festlegen
Pfeil 22.2.7 Beschriftungen mit @DisplayName
Pfeil 22.2.8 Verschachtelte Tests
Pfeil 22.2.9 Tests ignorieren
Pfeil 22.2.10 Mit Methoden der Assumptions-Klasse Tests abbrechen
Pfeil 22.2.11 Parametrisierte Tests
Pfeil 22.3 Java-Assertions-Bibliotheken und AssertJ
Pfeil 22.3.1 AssertJ
Pfeil 22.4 Aufbau größerer Testfälle
Pfeil 22.4.1 Fixtures
Pfeil 22.4.2 Sammlungen von Testklassen und Klassenorganisation
Pfeil 22.5 Wie gutes Design das Testen ermöglicht
Pfeil 22.6 Dummy, Fake, Stub und Mock
Pfeil 22.7 JUnit-Erweiterungen, Testzusätze
Pfeil 22.8 Zum Weiterlesen
 

Zum Seitenanfang

22.4    Aufbau 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

22.4.1    Fixtures 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 (die sich von Version 4 zu Version 5 geändert haben). Wie sie wirken, zeigt folgendes Beispiel:

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

package com.tutego.insel.junit.util;



import java.util.logging.Logger;

import org.junit.jupiter.api.*;



public class FixtureDemoTest {



static final Logger log = Logger.getLogger( FixtureDemoTest.class.getName() );



@BeforeAll

public static void beforeClass() { log.info( "@BeforeAll" ); }



@AfterAll

public static void afterClass() { log.info( "@AfterAll" ); }



@BeforeEach

public void setUp() { log.info( "@Before" ); }



@AfterEach

public void tearDown() { log.info( "@After" ); }



@Test

public void test1() { log.info( "test 1" ); }



@Test

public void test2() { log.info( "test 2" ); }

}

Die Annotationen beziehen sich auf zwei Anwendungsfälle:

  • @BeforeAll, @AfterAll: 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.

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

Läuft unser Beispielprogramm, ist die (verkürzte) Ausgabe daher wie folgt:

INFO: @BeforeAll

INFO: @Before

INFO: test 1

INFO: @After

INFO: @Before

INFO: test 2

INFO: @After

INFO: @AfterAll

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

[zB]  Beispiel

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

private static String oldValue;

@BeforeAll public static void beforeClass() {

oldValue = System.getProperty( "property" );

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

}

@AfterAll public static void afterClass() {

if ( oldValue != null ) {

System.setProperty( "property", oldValue );

oldValue = null;

}

}
 

Zum Seitenanfang

22.4.2    Sammlungen 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 physisch zu trennen. Entwicklungsumgebungen bieten hierzu Konzepte: So kann Eclipse unterschiedliche Quellcodeordner verwenden, die physisch und visuell getrennt sind, aber letztendlich zu Klassendateien im gleichen Paket führen. Nach dem Maven-Standard-Verzeichnis-Layout sind das src/main/java und src/test/java. 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.

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.

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java ist auch eine Insel Java ist auch eine Insel

Jetzt Buch bestellen


 Buchempfehlungen
Zum Rheinwerk-Shop: Captain CiaoCiao erobert Java

Captain CiaoCiao erobert Java




Zum Rheinwerk-Shop: Java SE 9 Standard-Bibliothek

Java SE 9 Standard-Bibliothek




Zum Rheinwerk-Shop: Algorithmen in Java

Algorithmen in Java




Zum Rheinwerk-Shop: Objektorientierte Programmierung

Objektorientierte Programmierung




 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2021

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



Cookie-Einstellungen ändern