Vor ein paar Tage ist eine neue Version veröffentlich worden. Dann mal ein Quicktest.
Was ist neu? Das gibt es hier.
Ergebnis des Quicktest: „JUnit 5 in Version 5.10.2 veröffentlicht“ weiterlesen
Wenzlaff.de – Rund um die Programmierung
mit Java, Raspberry Pi, SDR, Linux, Arduino, Sicherheit, Blender, KI, Statistik, Krypto und Blockchain
Vor ein paar Tage ist eine neue Version veröffentlich worden. Dann mal ein Quicktest.
Was ist neu? Das gibt es hier.
Ergebnis des Quicktest: „JUnit 5 in Version 5.10.2 veröffentlicht“ weiterlesen
In der Regel soll ja nur eine assertion pro Testmethode enthalten sein. Manchmal gibt es aber doch sinnvolle UseCases, dann kann man die assertAll verwenden.
Die assertAll-Methode in JUnit 5 wird verwendet, um mehrere Assertions innerhalb einer Testmethode zu gruppieren. „assertAll in Java“ weiterlesen
Diese JRE Enum gibt es auch schon seit 5.1 in JUnit 5.
Tests sollen eigentlich nicht an der Java Version hängen. Aber manchmal braucht man sie doch. „Java Runtime Environment Conditions mit JUnit 5 mit ua. EnabledForJreRange“ weiterlesen
Eben ist die neue Version JUnit 5.9.0 M1 veröffentlicht worden. Dann mal ein Quicktest. Ergebnis alles noch grün:
Was gibt es Neues? „Quicktest JUnit 5.9.0 M1 alles GRÜN“ weiterlesen
Warum wird in JUnit 5-Test kein public mehr verwendet? „Less is more“ sagt das JUnit-5 Team und die Testklassen liegen ja eh meistens im gleichen (Test) Package. Auch ist so eine besser Kapselung möglich.
Wenn man eine REST-Api überprüfen will, ob ein Timeout auftritt, kann man die @Timeout Annotation von JUnit 5 verwenden.
Z.B. wenn der REST-Service nicht nach 2 Sekunden (es gehen auch Tage, Stunden, Ms, …) zurückkommt, schlägt der JUnit Test fehl:
@Timeout(value = 2, unit = TimeUnit.SECONDS)
Seit JUnit 5.1 gibt es das OS Enum. Mit der können leicht Tests in Abhängigkeit des OS durchgeführt werden. Es werden die folgenden Betriebssysteme unterstüzt:
Also nur die Methode z.B. mit der @EnabledOnOs(OS.MAC) Annotation versehen, und der Test läuft nur auf dem Mac 🙂 oder nicht dann mit @DisabledOnOs(OS.MAC): … „Betriebssystem abhängige Tests 🙁 – EnabledOnOs oder DisabledOnOs für JUnit 5“ weiterlesen
Vor zwei Tagen wurde die neue JUnit Version 5.6.0 veröffentlicht.
Also die BOM aktuallisieren:
1 2 3 4 5 6 |
<dependency> <groupId>org.junit</groupId> <artifactId>junit-bom</artifactId> <version>5.6.0</version> <type>pom</type> </dependency> |
Und ein kleiner Test mit zwei Projekten: „Quicktest: JUnit 5.6.0 – „Freut euch immer““ weiterlesen
Vor zwei Tagen wurde die neue Version veröffentlicht:
Dann mal die pom.xml updaten und einen Quicktest:
„Neue Version graphviz-java-parent-0.11.0 vor zwei Tagen veröffentlicht“ weiterlesen
Mit der @CsvSource Annotation in JUnit 5 kann man mit Kommaseparierte Parameter leicht und übersichtliche Tests schreiben. Die API ist aber noch im EXPERIMENTAL Status.
Hier mal ein Beispiel. Für jeden Kommandozeilen Parameter eine Testmethode schreiben:
„JUnit 5 Quickie: @CsvSource“ weiterlesen
Warum wird beim ausführen dieses JUnit 5 Tests die Fehlermeldung angezeigt, das kein Test vorhanden ist?
Es ist nicht die fehlende @Test Annotation, die wird bei einem @ParameterizedTest nicht gebraucht.
Die Lösung …
„Rätsel des Tages: Warum läuft der JUnit 5 Test nicht und zeigt eine Message Box an?“ weiterlesen
Was gibt es neues in JUnit 5.3.0-M1?
Hier eine Beispiel POM: „JUnit 5 mit 5.3.0-M1 auf Photon mit Maven läuft!“ weiterlesen
Mit den neuen Tags (org.junit.jupiter.api.Tag) können Methoden und auch ganze Klassen getagt werden, um sie z.B. in Gruppen einzuteilen.
Eine Testgruppe könnte z.B. eine langlaufende DB Methoden sein, die nicht immer ausgeführt werden soll.
Ein Tag muss folgenden Syntax Regeln folgen:
-ein Tag darf nicht Leer sein
-ein Tag darf keine Leerzeichen enthalten
-ein Tag darf keine ISO Kontroll Zeichen enthalten
-ein Tag darf kein, (, ), %, | oder ! Zeichen enthalten
Eine Testklasse zur WM 2018 könnte so aussehen:
„Es muss ja nicht immer Fussball und Weltmeisterschaft sein! Neue Annotation für JUnit 5 – Tags sind auch spannend!“ weiterlesen
In JUnit 5 gibt es im Package org.junit.jupiter.api
die Klasse Assumptions
(Annahme).
Die Assumptions Klasse ist eine Sammlung von Util-Methoden. Im Gegensatz zu den Assertions
(Behauptungen) wird die Assumptions im Fehlerfall nicht mit einem failure (graues Kreuz) sondern mit einem Error (rot) markiert.
Deshalb ist es manchmal gewünscht, wenn z.B. eine Bestimmte Umgebung nicht vorhanden ist, das dann der Test nicht als Error (rot) sondern mit einen grauen Kreuz (Failures) markiert wird. Dann sollte man also die org.junit.jupiter.api.Assertions
verwenden wie diese Testklasse zeigt:
Hier der Quellcode „JUnit 5: Class Assumptions vs. Assertions – org.junit.jupiter.api – Behauptungen – Annahme – założenia – допущения -假設 – الافتراضات“ weiterlesen
Wenn man an einer zentralen Stelle Testmethoden annotieren will, geht das mit JUnit 5 über eigene Benutzer Annotationen. Ich habe mir eine Annotation für Performance Test geschrieben. Z.B. kann ich sie dann zentral ausschalten:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
package de.wenzlaff.umgebung; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; import org.junit.jupiter.api.Disabled; import org.junit.jupiter.api.Tag; /** * Annotation für Performance Tests. Zentral ausgeschaltet. * * @author Thomas Wenzlaff www.kleinhirn.eu */ @Disabled @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Tag("Performance") public @interface Performance { } |
In diesem Testlauf, habe ich mit der Annotation, die lange laufenden Test ausgeschaltet:
Wofür nutzt ihr die Custom Composed Annotation? Gern als Kommentar…
Nun ist endlich das finale GA Release 5.0 veröffentlicht worden. Diese Änderungen sind in der pom.xml nötig, und schon läuft es mit JUnit 5.
„Kaum ist man im Urlaub, erscheint nicht der Raspberry Pi 4 oder 5 sondern das GA Release von JUnit 5“ weiterlesen
Manchmal möchte man sehen, wie der vorletzte Testlauf abgelaufen ist. Man kann defaultmäßig die letzten 10 Testläufe wieder zur Anzeige bringen über: „Junit 5 History oder „Was bisher geschah …“ unter Eclipse (Oxygen)“ weiterlesen
Manchmal möchte man die lokalen JUnit 5 Testergebnisse für später aufheben oder als Doku verwenden oder sichern. Man kann die Ergebnisse als XML exportieren und auch später wieder importieren. So kann man sich dann Fehler oder Laufzeiten mal wieder anschauen.
Die Import und Export Menüs, erscheinen aber nur, wenn schon mal ein JUnit Test gelaufen ist, dann an dieser Position:
„JUnit 5 Test-Ergebnisse Import und Export im XML Format mit Eclipse Oxygen“ weiterlesen