© Excellent backgrounds/Shutterstock.com
Java-8-Features in JUnit-Tests

Tests besser wiederverwenden


Dieser Artikel ist kein Plädoyer für das allumfassende Testen von Softwarekomponenten; er ist auch keine Aufforderung zur Verwendung allein testgetriebener Vorgehensmodelle. Vielmehr stellt dieser Artikel mit J8Unit einen pragmatischen Ansatz für eine deutlich verbesserte Wiederverwendbarkeit von Testcode vor, der sowohl an Tester als auch an API-Designer gerichtet ist.

Erfahrungsgemäß lässt sich kaum ein Softwareentwickler finden, der nicht mindestens per Lippenbekenntnis die Relevanz von Softwaretests, insbesondere automatisierter Unit Tests, bestätigen würde. Für Drittbibliotheken gilt jedoch, dass – neben der Annahme, diese seien zumindest funktional hinreichend getestet – selten Testcode existiert oder bereitgestellt wird. Einer der Gründe für diese Situation ist die oft unterschiedliche Herangehensweise an die Programmierung von Code und Testcode. Die eigentliche Software soll häufig den üblichen Qualitätskriterien genügen (z. B. ISO/IEC 25000). Testcode hingegen wird eher begleitend erstellt und ohne wesentliche Eigenschaften zu beachten – insbesondere die Wiederverwendbarkeit. Wenn überhaupt, wird Testcode eher aus dokumentarischen Gründen bereitgestellt als mit der Intention, diesen nachnutzbar zu gestalten. Dies zwingt den Nutzer eines API dazu, gleichartige, unter Umständen duplizierte Tests für die eigenen Komponenten nach seinem API-Verständnis zu implementieren.

Doch selbst wenn nachnutzbarer Testcode bereitsteht, gestaltet es sich problematisch, diesen wiederzuverwenden, da bei derartigen Methoden (Listing 1) viel unnötiger Boilerplate-Code entstehen muss, um die Testmethoden jeweils mit dem passenden Testsubjekt (Subject Under Test, SUT) aufzurufen (Listing 2). Alternativ werden nachnutzbare Testmethoden über entsprechende Testklassenhierarchien bereitgestellt (Listing 3). Das schränkt allerdings die Freiheit des Testers ein, da er einer vorgegebenen Vererbungslinie folgen muss (Listing 4). Beide Varianten sind daher nur bedingt praktikabel.

Listing 1

import org.junit.*; public class ReusableTests { public static void testFoobar1(Foobar sut) {  // ... Assert.assertXXX(...); } public static void testFoobar2(Foobar sut) {  // ... Assert.assertXXX(...); } }

Listing 2

import org.junit.*; public class OldStyleTest1 { @Test public void testFoobar1() { Foobar sut = new Foobar(); ReusableTests.testFoobar1(sut); } @Test public void testFoobar2() { Foobar sut = new Foobar(); ReusableTests.testFoobar2(sut); } }

Listing 3

import org.junit.*; publi...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang