Entdecken Sie das TÜV-zertifizierte GoogleTest mit Agentic AI für C/C++-Tests!
Details ansehen »
Parasoft-Blog
Verstehen Sie die Grundlagen und skalieren Sie Ihre Unit-Test-Praxis wie ein Profi mit diesem Tutorial.
Zum Abschnitt springen
Möchten Sie die Grundlagen überspringen und sehen, wie Sie automatisieren können? Unit-Test-Generierung mit KI erweitert in <0 Minuten von 60 auf über 5 % Codeabdeckung gehen? Schauen Sie sich Jtest an >>
JUnit ist das beliebteste Framework für Java-Komponententests. Ein Open-Source-Framework, das zum Schreiben und Ausführen wiederholbarer automatisierter Tests verwendet wird.
JUnit hat sich durch die Kombination leistungsstarker, durchdachter und nahtlos zusammenarbeitender Funktionen als De-facto-Standard für Java-Unit-Tests etabliert. Es war das erste entwickelte Unit-Test-Framework und ist dank seiner besonderen Eigenschaften und kontinuierlichen Weiterentwicklung bis heute die bevorzugte Wahl für Java-Entwickler weltweit.
Wie alles andere hat sich auch das JUnit-Testframework im Laufe der Zeit weiterentwickelt.
JUnit 4.0 wurde 2006 veröffentlicht, 5.0 im Jahr 2017 und 6.0 im September 2025.
Stand Februar 2026 ist die aktuellste Version 6.0.2.
Hier sind einige der wichtigsten Aspekte und Funktionen von JUnit sowie die Unterschiede zwischen den Versionen:
| Merkmal/Aspekt | Einheit 4 | Einheit 5 | Einheit 6 |
|---|---|---|---|
| Ursprüngliches Erscheinungsjahr | 2006 | 2017 | 2025 |
| Architektur | Monolithische Architektur mit vollständiger Funktionalität in einem einzigen Behälter | Bietet 3 Module: JUnit Platform (Grundlage zum Starten von Tests), JUnit Jupiter (API zum Schreiben von Tests) und JUnit Vintage (führt ältere Tests aus) | Alle 3 Module haben nun die gleiche Versionsnummer. |
| Mindestversion von Java | 5 | 8 | 17 |
| Testbenennung | Der Methodenname dient als Testname | Das @Anzeigename Annotationen ermöglichen beschreibende, für Menschen lesbare Testnamen | Dasselbe wie JUnit 5 |
| Auf- und Abbau der Tests | Bietet Annotationen zur Konfiguration des Zustands vor jedem oder allen Tests in einer Klasse: @Vorher, @Nachher, @VorDerKlasse, @NachDerKlasse | Bietet verschiedene Annotationen, um den Zustand vor jedem Test oder vor allen Tests in einer Klasse zu konfigurieren: @BeforeEach, @AfterEach, @BeforeAll, @Afterall | Dasselbe wie JUnit 5 |
| Behauptungen | Bietet Methoden in org.junit.Assert Eine Klasse dient der Überprüfung der erwarteten Ergebnisse. Schlägt eine Überprüfung fehl, werden die übrigen nicht ausgeführt. | Bietet Methoden in org.junit.jupiter.api.Assertions Klasse mit verbesserten Fehlermeldungen, einschließlich assertAll () Mehrere Aussagen gleichzeitig zu überprüfen, unabhängig davon, ob eine davon fehlschlägt. | Dasselbe wie JUnit 5 |
| Überprüfung erwarteter Ausnahmen | Bietet @Test(expected = Exception.class) Annotation zur Überprüfung, ob eine Assertion ausgelöst wurde, aber Fehlermeldung und Details können nicht verifiziert werden. | Bietet assertThrows () Methode, die detaillierte Aussagen zu Fehlermeldungen und Details ermöglicht. | Dasselbe wie JUnit 5 |
| Leistungsüberprüfung und -durchsetzung | Bietet @Test(timeout = 1000) Annotation, um sicherzustellen, dass der Test nicht über die erwartete Zeit hinaus läuft und um unendlich lange Tests zu verhindern. | Bietet assertTimeout () , assertTimeoutPreemptively () Methoden zur Überprüfung der Leistung bestimmter Codeblöcke und @Auszeit Anmerkung für den gesamten Test | Dasselbe wie JUnit 5 |
| Parametrisierte Tests | Erfordert einen separaten Runner, der von @RunWith(Parameterized.class) Annotation innerhalb einer separaten Testklasse | Erstklassiger Support über @ParametrierterTest Annotation, die es ermöglicht, parametrisierte Tests mit nicht parametrisierten Tests zu mischen | Verwendet einen modernen CSV-Parser für besseres Verhalten und höhere Leistung. @CsvSource , @CsvFileSource Anmerkungen |
| Deaktivierungstests | Bietet @Ignorieren Annotation, die den Test stillschweigend überspringt | Bietet @Behindert Annotationen sowohl für einzelne Testmethoden als auch für ganze Klassen, die die Meldung eines Grundes unterstützen | Dasselbe wie JUnit 5 |
| Verschachtelte Tests | Nicht unterstützt | Bietet @Nested Annotation, die innere Testklassen für eine bessere Organisation verwandter Tests ermöglicht | Aktualisierte Reihenfolge für @Nested Klassen, die in derselben umschließenden Klasse oder Schnittstelle deklariert sind |
| Testgruppierung | Bietet @Kategorie Annotationen zur Gruppierung von Tests, erfordern jedoch separate Runner- und Kategorieklassen. | Bietet @Etikett Annotation zur Gruppierung von Tests mithilfe einer einfachen Bezeichnung; erfordert keinen separaten Runner. | Dasselbe wie JUnit 5 |
| Testvoraussetzungen | Bietet Methoden in Annehmen Klasse zur Steuerung, ob ein Test basierend auf bestimmten Umgebungsfaktoren ausgeführt wird. | Bietet eine verbesserte Annahmemethode Annahmen.annehmenDass() das eine detaillierte Steuerung der Ausführung eines bestimmten Codeblocks basierend auf der Umgebung ermöglicht | Dasselbe wie JUnit 5 |
| Verhaltensanpassung | Bietet Test-Runner und Regeln zur Unterstützung der Anpassung des Verhaltens des Test-Frameworks, weist jedoch einige Einschränkungen auf. | Verwendet ein einziges flexibles Erweiterungsmodell | Verwendet dasselbe Erweiterungsmodell wie JUnit 5, wurde aber bereinigt. |
| Rückwärtskompatibilität | Kann JUnit 3-Tests ausführen | JUnit-3- und JUnit-4-Tests können über die Vintage-Engine ausgeführt werden. | Der Vintage-Motor existiert zwar noch, ist aber veraltet. |
Diese Funktionen ergänzen sich synergistisch und bilden ein vollständiges, erweiterbares Framework, das professionelle Softwareentwicklungspraktiken unterstützt.
Dann legen wir mal los. Hier sind die Schritte zum Einrichten von JUnit.
In den gängigeren IDEs wie Eclipse und IntelliJ ist die JUnit-Testintegration bereits standardmäßig installiert.
Wenn Sie keine IDE verwenden und sich stattdessen ausschließlich auf ein Build-System wie Maven oder Gradle verlassen, erfolgt die Konfiguration von JUnit über die Datei pom.xml bzw. build.gradle.
Es ist wichtig das zu beachten Einheit 5 wurde in drei Module aufgeteilt, von denen eines ein älteres Modul ist, das die Ausführung von Einheit 4 und drei Tests von Einheit 5.
Einheit 6 Diese Architektur bleibt erhalten.
Einheit 3 Die Nutzung ist derzeit sehr gering und findet sich üblicherweise nur in viel älteren Projekten.
Aufgrund des modularen Aufbaus von JUnit 6 wird eine Stückliste (POM) zum Importieren aller JUnit-Module und -Abhängigkeiten verwendet. Werden nur bestimmte Module benötigt, können stattdessen einzelne Gruppen oder Artefakte angegeben werden.
Fügen Sie pom.xml Folgendes hinzu, um Javen JUnit 6 zu Maven hinzuzufügen:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.junit</groupId>
<artifactId>junit-bom</artifactId>
<version>6.0.2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.junit</groupId>
<artifactId>junit-bom</artifactId>
<version>6.0.2</version>
<scope>test</scope>
</dependency>
</dependencies>
Fügen Sie für Gradle Folgendes zur Datei build.gradle hinzu:
dependencies {
testImplementation platform("org.junit:junit-bom:6.0.2")
testImplementation "org.junit.jupiter:junit-jupiter-api"
testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine"
testRuntimeOnly "org.junit.platform:junit-platform-launcher"
}
test {
useJUnitPlatform()
}
Aufgrund des modularen Aufbaus von JUnit 5 wird eine Stückliste (POM) zum Importieren aller JUnit-Module und -Abhängigkeiten verwendet. Werden nur bestimmte Module benötigt, können stattdessen einzelne Gruppen oder Artefakte angegeben werden.
JUnit 5 wird auf die gleiche Weise konfiguriert wie JUnit 6:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.junit</groupId>
<artifactId>junit-bom</artifactId>
<version>5.14.2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.junit</groupId>
<artifactId>junit-bom</artifactId>
<version>5.14.2</version>
<scope>test</scope>
</dependency>
</dependencies>
Fügen Sie für Gradle Folgendes zur Datei build.gradle hinzu:
dependencies {
testImplementation platform("org.junit:junit-bom:5.14.2")
testImplementation "org.junit.jupiter:junit-jupiter-api"
testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine"
testRuntimeOnly "org.junit.platform:junit-platform-launcher"
}
test {
useJUnitPlatform()
}
Um JUnit 4 zu Maven hinzuzufügen, fügen Sie Folgendes zu pom.xml hinzu.
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>
Fügen Sie für gradle Folgendes zur build.gradle hinzu:
dependencies {
testImplementation 'junit:junit:4.13.2'
}
test {
useJUnit()
}
Falls Sie JUnit für JUnit-Tests manuell zum Klassenpfad hinzufügen müssen, müssen Sie die JAR-Datei(en) direkt referenzieren. Dies ist jedoch normalerweise nicht erforderlich. JUnit 4, 5 und 6 bieten die JAR-Datei(en) zum direkten Download an. Für JUnit 5 und 6 benötigen Sie eine Fat-JAR-Datei (auch Uber-JAR genannt), wie beschrieben. werden auf dieser Seite erläutert.
Verbessern Sie Unit-Tests für Java mit Automatisierung: Best Practices für Java-Entwickler
Nachdem wir nun ein wenig über das JUnit-Setup gesprochen haben, wollen wir mit der eigentlichen Konstruktion und Ausführung dieser Tests fortfahren. Um die Erstellung von JUnits am besten zu veranschaulichen, beginnen wir mit etwas Grundlegendem. Im folgenden JUnit-Testbeispiel haben wir eine einfache Methode (links), der Fahrenheit in Celsius umwandelt, und einen JUnit-Test (Recht) geschrieben, um unsere Methode zu testen. Ich habe die wichtigsten Teile des JUnit-Tests nummeriert und werde jeden Teil unten im Detail besprechen.
Die Teile 1 und 2 im obigen Screenshot zeigen die Importe der JUnit-Klassen und -Methoden, die im Unit-Test verwendet werden. Die Importe können als einzelne Klassen oder Methoden angegeben werden, üblicherweise werden jedoch ganze Pakete mit Sternchen (*) angegeben. Beide Varianten funktionieren – die Granularität der Importe ist Geschmackssache.
Teil 3 definiert den Beginn unserer Testklasse. Wichtig hierbei ist die Namenskonvention für die Klasse, die wie folgt lautet: KlassennameTest. Diese Namenskonvention ist nicht erforderlich, aber es ist die gebräuchlichste Art, JUnit-Klassen zu benennen, da der Name den Zweck der Unit-Test-Klasse und die Klasse, die sie testet, prägnant beschreibt.
In Teil 4 lernen wir unsere erste JUnit-spezifische Syntax kennen: die @Test-Annotation. Annotationen sind beim Erstellen von JUnit-Tests extrem wichtig. Sie dienen dem JUnit-Framework dazu, die relevanten Teile des Unit-Tests zu identifizieren. In unserem Beispiel weist die @Test-Annotation JUnit an, die öffentliche void-Methode, an die sie angehängt ist, als Testfall auszuführen.
Es gibt noch viele weitere Annotationen, aber einige der gebräuchlichsten für JUnit 5 und 6 sind die folgenden.
Beachten Sie für Teil 5 erneut die Namenskonvention. testMethodenname, Wobei Methodenname ist der Name der Methode, die in der zu testenden Klasse getestet wird. Diese Namenskonvention ist üblich, aber nicht zwingend erforderlich. Manchmal wird dem Namen eine zusätzliche Beschreibung hinzugefügt, um das spezifische Verhalten zu beschreiben, das durch den Test überprüft wird.
In Teil 6, Gegeben Abschnitt des Tests konstruieren wir eine neue Instanz der zu testenden Klasse und initialisieren sie entsprechend. Dies ist notwendig, da die Testmethode die zu testende Methode aufrufen muss, um sie zu testen. In unserem Beispiel ist neben der Instanziierung der Klasse keine weitere Initialisierung erforderlich, aber in vielen Fällen müssen möglicherweise zusätzliche Einstellungen vorgenommen werden, z. B. das Initialisieren von Objekten zur Übergabe an den Konstruktor oder das Aufrufen von Methoden, die den Zustand der zu testenden Klasse konfigurieren.
In Teil 7, Wenn die Funktion Der Abschnitt des Tests umfasst das Initialisieren von Variablen, die übergeben werden müssen, wenn die zu testende Methode aufgerufen wird, und dann das Aufrufen der Testmethode (Teil 8). Den Variablen sollten aussagekräftige Werte gegeben werden, die bewirken, dass der Test die Teile der Testmethode ausführt, die uns wichtig sind. Beachten Sie, dass eine Variable, die ein Objekt ist, instanziiert oder verspottet werden kann.
In Teil 8 sollte, falls die zu testende Methode einen Wert zurückgibt, dieser in einer Variablen gespeichert werden, damit sein Wert überprüft werden kann.
Unit-Tests sind nur dann sinnvoll, wenn sie Assertions enthalten, die überprüfen, ob die getestete Methode den korrekten Wert zurückgibt und/oder den Zustand anderer Objekte wie erwartet anpasst. Ohne Assertions, wie in Teil 9 gezeigt, findet keine Verifizierung statt. Ihr Test ist bestenfalls ein Smoke-Test, der nur dann Feedback liefert, wenn eine Ausnahme ausgelöst wird.
Die JUnit-Assertionsmethoden, die in JUnit 5 und 6 in der Klasse `org.junit.jupiter.api.Assertions` und in JUnit 4 in der Klasse `org.junit.Assert` enthalten sind, werden häufig verwendet, um den Status von Testfällen (bestanden/nicht bestanden) zu ermitteln. Nur fehlgeschlagene Assertions werden vom JUnit-Framework gemeldet. Ähnlich wie bei Annotationen gibt es zahlreiche Assertionsoptionen.
In unserem obigen Beispiel-JUnit verwenden wir die Methode assertEquals (erwartet, aktuell, Delta). Das erste Argument ist:
Wähle dein eigenes Abenteuer! Hier betrachten wir drei Möglichkeiten, JUnits auszuführen:
Suchen Sie im Paket-Explorer Ihren JUnit-Test. Klicken Sie mit der rechten Maustaste und wählen Sie Ausführen als > JUnit-Test. Dadurch werden Ihre Test- und Berichtsergebnisse in der JUnit Eclipse-Ansicht ausgeführt.
Das Ausführen eines Tests in IntelliJ ähnelt Eclipse. Suchen Sie im Projektfenster Ihren Test, klicken Sie mit der rechten Maustaste, und wählen Sie „Testname“ ausführen aus. Wie bei Eclipse öffnet sich ein JUnit-Fenster mit den Ergebnissen des Tests.
Maven vereinfacht das Ausführen von Unit-Tests. Stellen Sie sicher, dass Sie sich im richtigen Verzeichnis Ihrer Konsole befinden und die pom.xml-Datei Ihres Projekts korrekt konfiguriert ist. Anschließend können Sie Ihre JUnit-Tests mit folgendem Befehl ausführen.
So führen Sie die gesamte Testsuite aus:
mvn test
So führen Sie einen oder mehrere einzelne/spezifische Tests durch:
mvn -D test=TestName test
Gradle hat, ähnlich wie Maven, das Ausführen von Tests vereinfacht.
So führen Sie die gesamte Testsuite aus:
gradlew test
So führen Sie einen oder mehrere einzelne/spezifische Tests durch:
gradlew -D test.single=testName test
Hinweis: Maven und Gradle sind ihre eigenen Bestien. Was hier gezeigt wird, ist minimal, um die Grundlagen abzudecken. Schauen Sie sich ihre Dokumentation an, wenn Sie mehr erfahren möchten.
Um ein JUnit direkt von der Kommandozeile aus auszuführen, benötigen Sie ein paar Dinge:
Am einfachsten lässt sich dies in JUnit 5 und 6 mit dem JUnit Console Launcher wie folgt bewerkstelligen.
java -jar /path/to/junit-platform-console-standalone-<version>.jar execute -cp /path/to/source/classes -cp /path/to/test/classes <test class name>
Hinweis: Das Ausführen eines Tests über die Befehlszeile erfolgt am häufigsten über einen CI/CD-Prozess, der in einem Buildsystem wie Jenkins oder Azure DevOps ausgeführt wird.
Unser Beispiel durchlief einen einfachen Unit-Test, und das ist natürlich nur der Anfang von Unit-Tests. Komplexere zu testende Methoden rufen möglicherweise Methoden in abhängigen Klassen auf oder verbinden sich mit externen Systemen wie einer Datenbank. In solchen Fällen kann es sinnvoll sein, den Code durch Mocking zu isolieren.
Mocking hilft dabei, Codeeinheiten zu isolieren, sodass sich unsere Komponententests nur auf die spezifische zu testende Klasse/Methode konzentrieren können. Das am häufigsten zum Mocking in JUnit-Tests verwendete Framework ist Mockito.
Um mehr über das Spotten zu erfahren, lesen Sie den Beitrag meines Kollegen: So automatisieren Sie einen Java-Komponententest, einschließlich Verspottungen und Behauptungen.
Wenn Unit-Tests so wichtig sind, warum werden sie dann nicht von allen konsequent durchgeführt? Trotz ihrer Bedeutung sind Unit-Tests nicht immer einfach zu implementieren und zu pflegen. Sie erfordern fundiertes Entwicklungswissen und kontinuierlichen Aufwand, um die Test-Suites aktuell zu halten. Daher werden Unit-Tests oft vernachlässigt – bis es zu Regressionen kommt.
Aber so muss es nicht sein.
Hier ist Parasoft Test kommt ins Spiel. Sein KI-gestützter Unit-Test-Assistent wurde entwickelt, um die Hürden beim Schreiben und Pflegen von Unit-Tests zu beseitigen. Mit nur wenigen Klicks können Teams, die bei 0 % beginnen, sofort loslegen. Codeabdeckung kann automatisch robuste Testsuiten generieren, die 60 % oder mehr ihres Java-Codes abdecken. Als eine Finanzdienstleistungsunternehmen bemerkte: „Seit wir Parasoft Jtest implementiert haben, konnten wir den Zeitaufwand für die Erstellung und Wartung von Unit-Tests erfolgreich um mehr als 50 % reduzieren.“
So kann Ihr Team Ihre Testpraxis skalieren.
Wenn Ihnen das Schreiben und Warten von JUnit-Tests wie eine lästige Pflicht vorkommt, ist es Zeit, Ihren Ansatz zu modernisieren. KI-gestützte Testlösungen wie diese können die Testerstellung von einem Engpass in einen strategischen Vorteil verwandeln – und Ihnen mehr Zeit für die Entwicklung großartiger Software geben.
Machen Sie Unit-Tests einfacher und schneller mit dem KI-gestützten Parasoft Jtest.
Probieren Sie es selbst mit einer kostenlosen 14-tägigen Testversion mit vollem Zugriff aus.