Rückblick: Java Forum Stuttgart 2016 – Das neue JUnit

(c) Java Forum Stuttgart 2016

(c) Java Forum Stuttgart 2016

Mit einem Besucherrekord konnte das Java Forum Stuttgart (JFS) in diesem Jahr aufwarten. Rund 1.700 Besucher kamen am 07. Juli zum 19. JFS ins Kultur- und Kongresszentrum Liederhalle (KKL). Damit gehört das Java Forum Stuttgart zu den wichtigsten Events der Java Community in Deutschland. Mit rund 50 Vorträgen und zwei BoF-Sessions gab es viel zu lernen und zu diskutieren. Neben der Wissensvermittlung stand aber natürlich auch das Networking im Zentrum der Veranstaltung. Für it-economics war in diesem, wie auch im letzten Jahr, Katharina Knaus als Moderatorin dabei. In diesem und dem folgenden Blogpost gibt’s einen Überblick über die spannendsten Themen und Neuerungen vom diesjährigen JFS. [1]

 

 

 

JUnit 5: The next generation of JUnit

JUnit ist schon länger das beliebteste Testwerkzeug [2] unter Java-Entwicklern. Die aktuelle Version, JUnit 4, ist bereits ein wenig in die Jahre gekommen und so ist es nur konsequent, dass mit Java 8 (und Java 9 in Sichtweite) auch JUnit aufgefrischt wird. Auf dem JFS widmete sich ein Vortrag von Marc Philipp (Citrix Online Germany) und Matthias Merdes (Heidelberg Mobil) mit anschließender Diskussionsrunde den Neuerungen bei JUnit 5 [3].

Die wichtigsten Neuerungen von JUnit 5:

  • Das Entwickler-Team hat sich den Erweiterbarkeits-Problemen der älteren JUnit Generationen angenommen und die Architektur von JUnit neu aufgesetzt.
    • Mit der neuen Architektur wird die API und der Mechanismus zum Ausführen der Tests sauber getrennt. Der Test Code ist somit nur noch von einer schlanken API abhängig anstatt von dem Alleskönner junit.jar.
    • Diese Unterteilung und die Trennung der Module für alte und neue Tests resultiert in der folgenden Architektur:
 
 

Sie bringt den weiteren Vorteil, dass JUnit 5 auf- und abwärtskompatibel ist. Das Modul Vintage unterstützt    JUnit 3.8 und JUnit 4 Tests, das Modul Jupiter stellt die JUnit 5 API bereit und die Engine, die diese API interpretieren kann. Des Weiteren ist es möglich eine eigene API und Engine zu schreiben und diese an die übergreifende JUnit Plattform anzudocken.

  • Mit assertAll mehrere asserts kombinieren
    Ein wichtiges Argument für die „Verify One Condition per Test“ Regel [4] ist die Annahme, dass, wenn ein assert fehlschlägt, die anderen nicht ausgeführt werden und somit die Lokalisierung der Defects schwieriger wird.  Das assertAll Feature entkräftet dieses Argument. Wenn alle asserts denselben Aspekt bzw. Testfall testen, kann es sinnvoll sein diese in einer Testmethode abzuhandeln. Beispielsweise kann die Überprüfung, ob eine Liste nur ein spezifisches Element enthält, am effektivsten mit den asserts size==1 and firstElement == expectedValue vorgenommen werden. Auf der anderen Seite ist der Entwickler nun mehr denn je gefordert seine Testmethoden sinnvoll zu stricken. Nur weil die Technik es zulässt heißt es noch lange nicht, dass die Prinzipien für gute Tests vernachlässigt werden sollen. 

  • Extensions: Den Test-Lifecycle kontrollieren
    Das Highlight des neuen Frameworks ist  die bisher nicht da gewesene Erweiterbarkeit. Mithilfe von Extensions kann man in den Lifecycle von JUnit kontrolliert eingreifen und alles abbilden wozu früher eine Kombination aus Runner, @Rule und @ClassRule notwendig war.

Das erste Meilenstein Release wurde veröffentlicht und kann getestet werden. Das zweite kommt Ende August. Der Final Release soll im November 2016 folgen. Die Entwickler haben um Feedback gebeten.

Weitere Informationen zum Framework und zu den Entwicklern findet man hier:  http://junit.org/junit5/.

Im nächsten Blogpost zum Java Forum Stuttgart, der am 26. Juli erscheint, geht es um Best Practices beim Software Improvement.

 

[1] http://2016.java-forum-stuttgart.de/de/Home.html

[2] http://blog.takipi.com/the-top-100-java-libraries-in-2016-after-analyzing-47251-dependencies/

[3] http://junit.org/junit5/docs/current/user-guide/

[4] Gerard Meszaros: xUnit Test Patterns: Refactoring Test Code, Addison-Wesley, 2007, S. 45, ISBN 978-0-131-49505-0