22.4    Aufbau größerer Testfälle 

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

 

22.4.1    Fixtures 

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.

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;

  }

}

 

22.4.2    Sammlungen von Testklassen und Klassenorganisation 

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 As • Junit 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.