Software-Testing-Einstieg mit Java bedeutet: Unit-Tests, Integrationstests, API-Tests und UI-Tests bilden eine Pyramide aufsteigender Komplexität und Laufzeit. Werkzeuge wie JUnit, WireMock, Selenium und Maven decken die einzelnen Stufen ab. Behavior Driven Development verbindet dabei technische Tests mit natürlichsprachiger Beschreibung im Given-When-Then-Format.
Das Wichtigste in Kürze
- Unit-Tests in Java liegen im Millisekundenbereich und werden häufig von Entwicklern selbst geschrieben, während UI-Tests mit Selenium bereits im Minutenbereich laufen und deutlich mehr Ressourcen verbrauchen.
- Testautomatisierung kostet nicht nur Personalaufwand, sondern auch Strom: wer 25 Browser parallel in verschiedenen Versionen betreibt, muss diesen Aufwand bewusst gegen den tatsächlichen Testbedarf abwägen.
- Maven steuert nicht nur Abhängigkeiten, sondern auch welche Tests in welchem Schritt der Build-Pipeline ausgeführt werden, was Testern direkte Kontrolle über die Test-Suite gibt.
- Behavior Driven Development eignet sich laut Pascal Moll auch für Testdatenmanagement: Datentabellen lassen sich direkt in Gherkin-Feature-Files einbetten, bei großen Mengen empfiehlt sich der Wechsel auf CSV-Dateien.
Worum es beim Testen wirklich geht, bevor Java ins Spiel kommt
Testen ist nicht gleich Testen. Hinter dem einen Wort stecken Dutzende Arten, ein System zu prüfen, und der Einstieg gelingt erst, wenn man die Grundbegriffe sauber trennt. Wer aus der Entwicklung kommt oder ganz ohne Programmierhintergrund startet, stolpert genau an diesem Punkt: Welche Testart greift wann, und braucht man überhaupt Code-Kenntnisse?
Die kurze Antwort: Ein Grundverständnis der Testkonzepte trägt unabhängig von der Programmiersprache. Die Konzepte lassen sich in Java genauso umsetzen wie in Python, nur die Syntax ändert sich. Java bleibt eine der weit verbreiteten Sprachen, deshalb lohnt es sich, die abstrakten Ideen einmal konkret in dieser Welt durchzuspielen.
Die Testpyramide in Java: von Millisekunden zu Minuten
Die Testpyramide ordnet Testarten nach Breite und Laufzeit, und im Java-Umfeld sieht sie klassisch aus. Unten liegt die breiteste Stufe, oben die schmalste, darüber schwebt noch etwas, das in keine feste Form passt.
An der Basis stehen Unit-Tests. Sie zerlegen die Software in einzelne Units, sind in wenigen Minuten geschrieben und laufen im Millisekundenbereich. In vielen Projekten schreiben Entwickler diese Tests selbst, weil sie schnell und direkt am Code ansetzen.
Eine Stufe höher werden Komponenten zusammengesteckt. Hier beginnt der Integrationstest, danach folgen Systemtests, und an der Spitze stehen Akzeptanztests. Mit jeder Stufe wächst das System, das geprüft wird, und damit die Laufzeit. UI-Tests, der Klassiker an der Spitze, liegen schon im Minutenbereich.
Über der Pyramide schwebt eine Wolke: die explorativen Tests. Sie folgen keiner festen Automatisierungsstruktur und ergänzen das, was die automatisierten Stufen abdecken.
Welche Tools die Java-Teststufen abdecken
Jede Stufe der Pyramide hat in Java ihre etablierten Werkzeuge. JUnit ist das Standard-Framework für Unit-Tests und hat Entsprechungen in anderen Sprachen, etwa NUnit in C#. Das Prinzip bleibt gleich, nur der Name wechselt.
Für API-Tests, eine Stufe höher, kommt Mocking ins Spiel, sobald eine Schnittstelle noch nicht vollständig vorliegt. WireMock ist hier ein gängiges Werkzeug, um fehlende Komponenten zu simulieren. Oberflächentests laufen über Selenium. Will man das Verhalten der Software in natürlicher Sprache beschreiben und prüfen, landet man beim Behavior Driven Development, das API-Tests und andere Stufen einbinden kann.
Die folgende Übersicht ordnet die wichtigsten Werkzeuge ihren Aufgaben zu:
| Stufe / Aufgabe | Werkzeug |
|---|---|
| Unit-Tests | JUnit |
| API-Tests mit Mocking | WireMock |
| Oberflächentests | Selenium |
| Verhaltensbeschreibung | Behavior Driven Development |
| Bibliotheken einbinden | Maven |
Maven ist mehr als ein Bibliotheksmanager
Maven steuert den gesamten Build-Zyklus und macht das Handling von Testcode leichter. Der Zyklus besteht aus mehreren Schritten, und jeder davon lässt sich konfigurieren. Schon ein Verify-Schritt prüft, ob die Konfiguration überhaupt gültig ist, bevor irgendetwas weiterläuft.
Der Kern ist das Bauen des Codes. Maven kompiliert, prüft, ob alles richtig konfiguriert ist, und zieht externe Bibliotheken oder Parameter. Weil die meisten Test-Tools bereits als Bibliotheken existieren, lassen sie sich darüber direkt integrieren, statt sie von Hand einzubinden.
Am Ende steuerst du, welche Tests laufen. Die komplette Suite, nur einzelne Tests oder ausschließlich Integrationstests: alles lässt sich über die Konfiguration festlegen. Das macht Maven zu einem praktischen Werkzeug, sobald die Testbasis wächst.
Tester und Entwickler schauen unterschiedlich auf denselben Code
Die wichtigste Eigenheit beim Testen von Java-Code ist die Perspektive, nicht die Sprache selbst. Wer Code schreibt, denkt zuerst an Lesbarkeit und Wartbarkeit. Edge Cases und Fallstricke geraten dabei leicht aus dem Blick.
Ein Tester dreht die Frage um: Was passiert bei ungültigen Werten? Stürzt die Software ab oder fängt sie den Fehler sauber? Diese Perspektive gehört direkt in den Java-Code, etwa über Exception Handling.
Fehlermeldungen sind selbst Testgegenstand. Man prüft, ob eine Exception überhaupt erscheint, ob sie an der richtigen Stelle auftaucht und ob nicht stattdessen etwas Unerwartetes passiert. Das Abtesten von Exceptions ist damit ein eigenes Feld, kein Nebenprodukt.
Wie Testdaten in Java verwaltet werden
Für Testdaten gibt es in Java mehrere Wege, und welcher passt, hängt vom Umfang ab. Im Behavior Driven Development lassen sich Daten direkt in die Feature Files schreiben. Dort wird in natürlicher Sprache nach dem Muster Given-When-Then formuliert: gegeben eine Situation, etwa ein geöffneter Browser, wenn ein Button geklickt wird, dann folgt eine Aktion.
Innerhalb dieser Gherkin-Szenarien sind Datentabellen die häufigste Form, Testdaten anzugeben. Sie hängen direkt im Feature File und stehen dem Test zur Verfügung. Das funktioniert gut, solange die Datenmenge überschaubar bleibt.
Überschreiten die Daten etwa hundert Zeilen, werden Tabellen im Feature File unübersichtlich. Dann eignen sich CSV-Dateien besser, die der Test einfach einlädt. Für größere oder dynamische Datenbestände lassen sich auch Datenbanken anbinden.
Nachhaltigkeit gehört in die Testplanung
Testen kostet nicht nur Personal, sondern auch Strom, und das ändert die Frage, wie viel man testet. Jeder Testfall, jede Build-Pipeline verbraucht Energie und Geld. Wer viele Testfälle ausführt, wirkt damit auf den eigenen Haushalt und auf die Umwelt.
Deshalb lohnt es sich, vorab das Ziel jedes Tests zu klären. In einem Bereich, in dem es um Menschenleben geht, gilt ein anderer Fokus als beim Prüfen eines Webformulars. Die Prioritäten verschieben sich, und damit auch die Frage, welche Testfälle wirklich nötig sind.
Java fällt dabei ins Gewicht, weil es ressourcenhungrig sein kann. UI-Testing lässt sich bis ins Unendliche treiben, etwa mit 25 parallel laufenden Browsern in unterschiedlichen Versionen. Das kostet. Sich diese Ausbaustufen vorher zu überlegen, spart Ressourcen, bevor sie verbraucht sind.
Es ist so viel Wissen drin, dass man darauf aufbauen kann. Wenn man das gelesen hat, hat man ein Grundverständnis und kann sich überlegen, in welche Richtung man weitergeht.
Pascal Moll
