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

Pfeil22 Testen mit JUnit
Pfeil22.1 Softwaretests
Pfeil22.1.1 Vorgehen beim Schreiben von Testfällen
Pfeil22.2 Das Test-Framework JUnit
Pfeil22.2.1 Test-Driven Development und Test-First
Pfeil22.2.2 Testen, implementieren, testen, implementieren, testen, freuen
Pfeil22.2.3 JUnit-Tests ausführen
Pfeil22.2.4 assertXXX(…)-Methoden der Klasse Assertions
Pfeil22.2.5 Exceptions testen
Pfeil22.2.6 Grenzen für Ausführungszeiten festlegen
Pfeil22.2.7 Beschriftungen mit @DisplayName
Pfeil22.2.8 Verschachtelte Tests
Pfeil22.2.9 Tests ignorieren
Pfeil22.2.10 Mit Methoden der Assumptions-Klasse Tests abbrechen
Pfeil22.2.11 Parametrisierte Tests
Pfeil22.3 Java-Assertions-Bibliotheken und AssertJ
Pfeil22.3.1 AssertJ
Pfeil22.4 Aufbau größerer Testfälle
Pfeil22.4.1 Fixtures
Pfeil22.4.2 Sammlungen von Testklassen und Klassenorganisation
Pfeil22.5 Wie gutes Design das Testen ermöglicht
Pfeil22.6 Dummy, Fake, Stub und Mock
Pfeil22.7 JUnit-Erweiterungen, Testzusätze
Pfeil22.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