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, 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
Unterstriche in JUnit 5 Test-Methoden und Klassen können auch per Default automatisch für alle Tests nach Leerzeichen konvertiert werden. Es sieht auch gleich besser aus:
Dazu einfach im src/test/resources Verzeichnis die Datei
junit-platform.properties anlegen mit diesem Eintrag: „Unterstriche in JUnit 5 Tests automatisch nach Leerzeichen konvertieren“ weiterlesen
Zum Wochenende mal ein kleines Quiz. Läuft der Test grün oder rot?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
import static org.junit.jupiter.api.Assertions.assertEquals; import org.junit.jupiter.api.Test; /** * Kleines Quiz am Freitag. * * @author Thomas Wenzlaff * */ class Quiz42 { private static void is42(String auswertung) { if (auswertung.startsWith("42")) { auswertung = "0815"; } else { auswertung = "4711"; } } @Test void isStart42Test() { String auswertung = "4212345"; Quiz42.is42(auswertung); assertEquals("4212345", auswertung); // Ist der Test grün oder rot? System.out.println("Das Ergebnis ist: " + auswertung); } } |
Die Lösung … „Rot oder Grün, das ist hier die Frage“ weiterlesen
Vor zwei Stunden wurde eine neue ArchUnit 0.0.22 veröffentlicht. Dann mal gleich ein Quicktest. Memory leak ist nun gefixt. Und es können Unterstriche durch Leerzeichen in Testnamen ersetzt werden:
1 2 3 |
@AnalyzeClasses(packages = "de.wenzlaff.package") @DisplayNameGeneration(DisplayNameGenerator.ReplaceUnderscores.class) public class SomeTestClass { ... } |
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.
Gestern die neue Version von ArchUnit 0.19.0 veröffentlicht. Dann mal ein Quicktest: … „ArchUnit in Version 0.19.0 veröffentlicht oder wie validiere ich die Architektur am Beispiel einer Blockchain“ weiterlesen
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
Auf der Terrasse sitzen geht wegen 0,5 Meter Schnee nicht
deshalb Ripemd-160 JUnit Test mit eine Millionen check implementiert. … „Auf der Terrasse sitzen geht wegen 0,5 Meter Schnee nicht, deshalb Ripemd-160 eine Millionen check“ weiterlesen
JUnit und auf Maven Central JUnit 5.7.0
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
Da heute ein arbeitsfreier Tag ist, schon mal eine kleine Vorbereitung („ARBEIT“) für den Einsatz im Projekt ab Montag. Da wollen wir JSON Objekte verwenden. Für die JSON Erzeugung mit Java gibt es viele Möglichkeiten und Libs. Hier mal ein kleines Beispiel mit der 68 kB großen json.org Lib.
Zuerst in der pom.xml die Lib eintragen:
1 2 3 4 5 |
<dependency> <groupId>org.json</groupId> <artifactId>json</artifactId> <version>20190722</version> </dependency> |
und dann einen kleine JUnit 5 Test.
1 2 3 4 5 6 7 8 9 10 11 12 |
@Test void kleinerJsonTest() { JSONObject json = new JSONObject(); json.put("name", "Wenzlaff"); json.put("vorname", "Thomas"); json.put("pin", 123456); // {"pin":123456,"vorname":"Thomas","name":"Wenzlaff"} assertEquals("{\"pin\":123456,\"vorname\":\"Thomas\",\"name\":\"Wenzlaff\"}" + "", json.toString()); } |
Also einfach ein JSONObject Objekt erstellen und mit put die Key und Value Werte eingeben. Für die put Methode gibt es viele Möglichkeiten: „Wie kann JSON in Java „schnell“ erzeugt werden?“ 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
In Eclipse kann man leicht die Testabdeckung visualisieren.
Wenn man z.B. einen JUnit Test über den Menüpunkt „Coverage As – JUnit Test“ ausführt:
Alle Zeilen die grün sind, wurden durchlaufen: „Eclipse Quickie: Testabdeckung anzeigen mit „Coverage As““ weiterlesen
Wie können die Testmethoden einer Klasse automatisch in alphabetischer Reihenfolge ausgeführt werden? Ab JUnit 5.4 geht das mit der Annotation @TestMethodOrder
Es wird nur die @TestMethodOrder(MethodOrderer.Alphanumeric.class) Annotation an der jeweiligen Test-Klasse benötigt. Mit dem Alphanumeric wird die Reihenfolge auf alphabetischer gesetzt. „JUnit Quickie: Wie können die Testmethoden einer Klasse automatisch in alphabetischer Reihenfolge ausgeführt werden?“ weiterlesen
Normal sollte die Testreihenfolge ja nicht festgelegt werden. Da eine Test-Methode nicht von einer anderen abhängig sein sollte.
Manchmal wird das aber dennoch benötigt. Das geht jetzt ab JUnit 5.4 ganz einfach mit der @Order Annotation.
Hier eine Beispiel Klasse. „JUnit Tests nun mit Methoden Reihenfolge via @Order Annotation möglich“ weiterlesen
Also mal testen ob alle läuft? Kleine Änderung in der pom.xml
1 2 3 4 |
<junit.version>4.12</junit.version> <junit.jupiter.version>5.4.0</junit.jupiter.version> <junit.vintage.version>5.4.0</junit.vintage.version> <junit.platform.version>1.4.0</junit.platform.version> |
Dann mal zwei Projekt umstellen. Siehe da, die Buildpipeline laufen auch noch wie erwartet:
und die auch „Letzte Woche wurde das JUnit 5.4.0 Release veröffentlicht“ weiterlesen
Es wurde vorgestern eine neue Version von JUnit 5 veröffentlicht,
siehe https://junit.org/junit5/docs/5.4.0-M1/release-notes/
Mindmap zum Thema „Neue M1 Version von JUnit 5.4.0 veröffentlicht“ weiterlesen
Ein REST-Client ist in zwei Zeilen mit Spring schnell geschrieben. Früher war es komplizierter! Hier mal eine JUnit-Testklasse: „Finale der Weltmeisterschaft 2018: REST Client in zwei Zeilen mit org.springframework.web.client.RestTemplate“ 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
Wie kann eine Vaadin Spring Boot mit Hibernate Anwendung auf JUnit 5 für Eclipse Oxygene 3A umgestellt werden?
1. Deaktivieren wir die JUnit (4.12) Libs in der pom.xml:
1 2 3 4 5 6 7 8 9 10 11 12 |
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> <!-- Kein JUnit 4 mehr für den Test--> <exclusions> <exclusion> <groupId>junit</groupId> <artifactId>junit</artifactId> </exclusion> </exclusions> </dependency> |
2. Fügen wir die nötigen JUnit 5 Libs in der pom.xml hinzu:
1 2 3 4 5 6 7 8 9 10 11 12 |
<!-- Alles für JUnit 5 --> <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-api</artifactId> <scope>test</scope> </dependency> <!-- and the engine for surefire and failsafe --> <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-engine</artifactId> <scope>test</scope> </dependency> |
3. Wir fügen JUnit 5 dem Buildpfad hinzu:
Es sieht dann so aus:
„Wie kann eine Vaadin Spring Boot Anwendung in 15 Minuten auf JUnit 5 umgestellt werden?“ weiterlesen
Mit shellcheck kann man gut Shell Scripte überprüfen.Das kann man einfach online, über diese GUI www.shellcheck.net ausprobieren oder aber auch installieren.
Für den Raspberry Pi gibt es schon ein installations Packet, deshalb ist die Installation mit
1 2 3 |
sudo apt install shellcheck # Testen welche Version installiert wurde# # version: 0.4.4 |
schnell erledigt.
Das ist nun nicht gerade die aktuelle Version 0.5.0 aber immerhin. Ein selbst compilieren kommt für den Pi nicht infrage, da ShellCheck in Haskell programmiert ist und da für den compile mind. 2GB RAM benötigt werden, der Pi hat aber je nach Version max. 1GB.
Nun kann leicht eine Script Datei überprüft werden, mit Aufruf
shellcheck SCRIPT.sh. Hier mal zwei Beispiele:
„Shell Scripte überprüfen mit ShellCheck auch auf dem Raspberry Pi (Zero W) in 5 Minuten möglich und auch JUnit via xslt“ 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
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
Mit Java 8 wird im bin Verzeichnis auch das JDeps Tool ausgeliefert. Dieses Tool ermöglicht eine statische Kodeanalyse von der Kommandozeile. Es kann die statischen Abhängigkeiten von Klassen und Jars aufzeigen und auch eine Abhängigkeitsgraphen generieren. So ist man dann für Java 9 vorbereitet.
Das wollen wir einmal ausprobieren. Dazu hole ich mir für mein Testprojekt erst einmal alle Jars und untersuche dann das JUnit 4.12.
Also in der pom.xml folgendes Plugin ergänze und ein „mvn package“ ausführen: „Quicktest: JDeps (Java Dependency Analysis Tool)“ weiterlesen
In JUnit 5 gibt es nun die Möglichkeit, Testmethoden mit Parametern ausszuführen. Anstatt der @Test Annnotation verwendet man die @ParameterizedTest. Nun braucht man noch eine Datenquelle mit @ValueSource.
Diese Klassen liegen in: „JUnit 5 @ParameterizedTest mit @ValueSource oder 3 Gründe warum man keine JUnit Tests schreiben sollte!“ weiterlesen
Wollte mal mein REST Testprogramm auf JUnit 5 umstellen. Die neuen JUnit 5 Feature sind schon sehr interessant. Vor ein paar Tagen ist der neue M6 veröffentlicht worden (JUnit 5.0.0-M6 = Platform 1.0.0-M6 + Jupiter 5.0.0-M6 + Vintage 4.12.0-M6). Auch ist die Architektur nun grundlegend geändert. Und evl. will man schon mal die Neuen Features testen. Es gilt nicht: „Wer testet ist Feige ;-)“
Was ist da so nötig?
JUnit 5 braucht zur Laufzeit Java 8.
Versionen setzen
1 2 3 4 5 6 7 8 9 10 11 12 |
<properties> <java.version>1.8</java.version> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <restlet-version>2.3.10</restlet-version> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <junit.version>4.12</junit.version> <junit.jupiter.version>5.0.0-M6</junit.jupiter.version> <junit.vintage.version>${junit.version}.0-M6</junit.vintage.version> <junit.platform.version>1.0.0-M6</junit.platform.version> </properties> |
Die neuen Abhängigkeiten hinzu: „Rest Test Programm: Java Migration von JUnit 4 nach JUnit 5 (1.0.0.-M6)“ weiterlesen
Einige Namen von Annotationen wurden in JUnit 5 gändert, also von @Ignore nach @Disabled und …
Weitere Details „Neue Annotationen الشروح in JUnit 5 (= JUnit Platform + JUnit Jupiter + JUnit Vintage) für Java 8“ weiterlesen
OpenSky bietet eine Java API an um auf Flugdaten zugreifen zu können. Da die live API nun wieder online ist, schreiben wir einen kleine JUnit Test und formen mal alle Transponderdaten aller 4754 Flugzeuge in eine KML Datei, um die Daten auf Google Earth anzuzeigen. Hier erst einmal das Ergebnis in Google Earth aus 5569 Km Höhe gesehen:
Wer die die Daten testweise laden will, „OpenSky Java API to KML für Google Earth – Teil 1“ weiterlesen
JUnit Testmethoden sollten so geschrieben werden, das sie unabhängig von anderen Methoden sind. Die Reihenfolge der ausführung der Test-Methoden in einer Testklasse ist auch nicht garantiert und kann von lauf zu lauf unterschiedlich sein. Das ist auch gut so.
Manchmal möche man aber dennoch eine bestimmte Reihenfolge. Dies kann seit JUnit 4.11 mit der @FixMethodOrder(MethodSorters.NAME_ASCENDING Annotation durchgeführt werden.
Die Testklasse wird einfach mit der @FixMethodOrder(MethodSorters.NAME_ASCENDING markiert. Z.B.
Ohne ist die Ausführung z.B.:
Und mit Annotation z.B.:
Nach über 2 Jahren ist nun eine neue Version von JUnit veröffentlicht worden. Die Releasenotes sind auf Github zu finden. In folgenden Bereichen gab es Ergänzungen:
Ok, dann mal gleich das aktuelle Maven Projekt TWFlug auf die neue Version 4.12 angepasst:
1 2 3 4 5 6 7 8 9 10 |
<properties> <junit.version>4.12</junit.version> </properties> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>${junit.version}</version> <scope>test</scope> </dependency> |
Mehr über JUnit oder drei Gründe warum man keine JUnit-Tests schreiben sollte.
Auf dieser Seite von Frank Westphal gibt es das E-Book „Testgetriebenen Entwicklung mit JUnit und Fit“ kostenlos zum download im PDF-Format.
Es ist immer noch sehr aktuell.
Vielen Dank für die kostenlose Bereitstellung.
Kennt ihr noch weitere gute kostenlose E-Books? Dann hinterlasst bitte hier einen Kommentar.
Die Regel, nur eine assert-Anweisung pro Testmethode zu verwenden, mag drakonisch klingen erleichtert aber die Übersicht (siehe Blog von Dave Astels).
Obwohl ich auch keine Angst habe von dieser Regel abzuweichen.
Was ist Eure Meinung? Wer testet ist feige?
Was ist richtig?
...
String testString = testobjekt.getTestwertAlsString();
// a:
assertEquals("expected", testString);
// oder
// b:
assertEquals(testString, "expected");
„JUnit – assertEquals“ weiterlesen