Ein Stück Zukunft für JUnit

JUnit Lambda – Mehr als nur Zucker

Dirk Dorsch

Vermutlich gibt es sie, die Software, die einfach mal fertig ist. Fertige Software zeichnet sich dadurch aus, dass sie allenfalls noch gewartet wird, es aber keine nennenswerten Erweiterungen mehr gibt. In den Wartungsmodus übergegangen, sinkt dann auch das Interesse an den entsprechenden Projekten. Hinsichtlich funktionaler Erweiterungen hat man von ihnen nicht mehr viel zu erwarten… Hier setzt das Projekt JUnit Lambda an.

Irgendwann werden die Projekte dann für beendet erklärt und auch der Wartungszyklus neigt sich dem Ende zu. Problematisch wird das insbesondere dann, wenn die Software Grundlage zahlreicher anderer Projekte oder sogar die Grundlage der Qualität der meisten Projekte ist. Es wäre fatal, wenn diese ebenfalls im Wartungsmodus versinkt, nicht mehr an zeitgemäße Konzepte angepasst wird. oder im Laufe der Zeit nicht mehr mit anderen Technologien, wie beispielsweise neuen Sprachversionen, kompatibel ist. Das JUnit-Lambda-Projekt schickt sich an, das wichtigste Testframework für die Zukunft vorzubereiten und unter anderem auf Basis der letzten Neuerungen von Java zu modernisieren.

Was bisher bei JUnit geschah

JUnit ist und war irgendwie schon immer da. Mit 43 Millionen Downloads allein im Jahr 2014 wird dies zusätzlich untermauert. Zahlreiche weitere Testing Frameworks bauen auf JUnit auf und unzählige  Projekte stützen ihre Qualitätssicherung auf dessen Basis. Als Teil der XUnit Frameworks ist JUnit wohl kaum mehr aus der Java-Welt wegzudenken und darf ohne Zweifel als eines der wichtigsten Projekte des Java-Ökosystems gesehen werden.

Ende des letzten Jahrtausends von Erich Gamma und Kent Beck – der Legende nach im Flugzeug – ins Leben gerufen, wurde JUnit in den vergangenen Jahren von der Community stetig weiterentwickelt. JUnit unterscheidet sich jedoch stark von vielen anderen Open-Source-Projekten. Entgegen zahlreicher anderer Projekte kann es sich nicht mit funktionalen Erweiterungen zur Umsetzung neuer Geschäftsanwendungen schmücken. Als Infrastrukturprojekt verliert es so über die Zeit schnell an Achtung und Aufmerksamkeit. Neue Releases von Java EE oder Spring werden über Monate hinweg gierig erwartet. So wird beispielsweise das Spring Framework auf GitHub aktuell von ca. 1349 Personen „beobachtet“, JUnit hingegen nur von 439 (Stand jeweils August 2015) und das trotz der eingangs erwähnten drastischen Download-Zahlen.

JUnit war irgendwie schon immer da. Und ein neues Minor-Release wird auch irgendwann wieder von alleine da sein. Die IDE oder andere Testinfrastrukturen bringen es irgendwann von alleine mit. Erweiterungen bekommt man mit oder eben auch nicht, wenn man Tests nur als „notwendiges Übel“ empfindet.

Das letzte große Release: JUnit 4

Mal ehrlich, erinnern Sie sich noch an das Release von JUnit 4 im Jahr 2006? Wann haben Sie Ihre Projekte von 3.8 auf 4 umgestellt und welche Neuerungen sind Ihnen in Erinnerung geblieben? Ein interessantes Phänomen war beispielsweise das „doppelte JUnit“. Während verwendete Web-Frameworks in ihrer Testinfrastruktur vielleicht schon JUnit 4 mitbrachten, hatten die eigenen Build-Skripte und/oder die IDE den Klassenpfad noch mit JUnit 3.8 bereichert. Eine hierbei augenscheinlich auftretende Änderung waren die neuen Paketnamen. Sofern Projekte und Infrastruktur nicht aufgeräumt wurden, besteht bis heute noch das Rätsel, welches Paket nun das richtige ist. (Es ist übrigens org.junit…)

Aber insbesondere gab es auch weitreichende Neuerungen und Verbesserungen, die erst durch neue Sprachfeatures aus Java 5 möglich wurden. So konnten durch die in Java 5 eingeführten Annotations weitreichende Verbesserungen in JUnit realisiert werden. Mit diesen wurde es beispielsweise möglich, beliebige Methoden mit @Before und @After als setUp() respektive tearDown() zu annotieren. Die Annotation @Test befreite vom verbindlichen Erben der Klasse TestCase und erhöhte die Lesbarkeit. Eine Testmethode muss somit nicht mehr mit „test“ beginnen, sondern kann gänzlich die Fachlichkeit im Namen widerspiegeln. Auch in Bezug auf die Erweiterbarkeit wurden in JUnit 4 einschneidende Neuerungen implementiert. Mit dem Runners-Konzept ist es möglich geworden, adaptierte Testtreiber für die Ausführung der Tests zu definieren. Spring-Entwicklern ist beispielsweise der SpringJUnit4ClassRunner ein treuer Begleiter geworden, lästiges Auslesen von Spring-Kontexten entfällt, und auch die Tests werden mit den notwendigen Services versorgt.

Nach einigen Maintenance Releases kamen in den Versionen 4.4 bis 4.12 auch einige funktionale Erweiterungen, wie beispielsweise eine neue Assertion-Syntax. Durch Theories und Assumptions wurden Tests nochmals lesbarer und wohlstrukturierter. (Method)Rules wurden zu TestRules und um ClassRules ergänzt. Zudem können Rules nun durch Verkettung kombiniert werden. Seit JUnit 4.11 können Tests mit @Paramterize und dem Parameterized Runner parametrisiert werden.

Auch in den vergangen Jahren wurde JUnit also durchaus attraktiv gehalten. Im Vergleich zu der einschneidenden Einführung der Annotations gingen diese Erweiterungen aber eher als „Zucker“ unter. Seien Sie ehrlich, welches waren die letzten JUnit-Release-Notes, die Sie intensiv studiert haben und deren Erkenntnisse Sie in Ihre Projekte haben einfließen lassen?

Der nächste Schritt: JUnit Lambda

Somit fand zwar auch in den letzten Jahren eine permanente Weiterentwicklung an JUnit statt, dennoch hat sich in den letzten Jahren eine Vielzahl von gewünschten Erweiterungen angesammelt. Analog der vergangen Jahre sollen bestehende Konzepte weiterhin verbessert, aber auch weitere Neuerungen integriert werden. So sollen die in Java 8 eingeführten und als Namensgeber dienenden Lambdas genutzt werden, Assertions erneut stilistisch aufzuwerten. Darüberhinaus werden durch Lambdas aber auch eine Definition von Testhierarchien und eine generative/programmatische Erzeugung von Testfällen möglich.

Die bisherigen Ansätze zur Erweiterbarkeit wie Runners, Rules und Subclassing sollen hinsichtlich ihrer Konsistenz zueinander überarbeitet werden und so eigene Erweiterungen erleichtern. Die Trennung der orthogonalen Belange, Testausführung und Reporting von der Testdefinition und Provisionierung soll die Basis für eine flexiblere Orchestrierung, aus beispielsweise Testspezifikation in Spock und Reporting über JUnit, schaffen. Fast 10 Jahre nach dem Release von JUnit 4 soll nun erneut eine grundlegende Erneuerung, aufbauend auf der aktuellsten Sprachversion von Java, realisiert werden, und so das Projekt auch für zusätzliche Erweiterungen vorbereiten.

Mit JUnit Lambda wird die Zukunftsfähigkeit des Projektes adressiert. Die geplanten Anpassungen sind weit mehr als nur Syntaxzucker. Mit der Unterstützung von Test für asynchronen Code oder der generativen/programmatischen Erzeugung von Testfällen sind einige große neue Funktionalitätsblöcke geplant, die moderne Konzepte in der Testimplementierung ermöglichen. Auch soll die technische Stabilität für auf JUnit aufsetzende oder integrierende Tools, wie IDEs und Build-Tools, verbessert werden. Einige dieser Tools nutzen interne Implementierungsdetails. Dies erschwert wahlweise die Weiterentwicklung von JUnit oder gefährdet die Stabilität dieser Tools. Um dem entgegen zu wirken, soll ein wohl definiertes API geschaffen werden, um so den Tool-Herstellern ein klar abgegrenztes API und insbesondere eine stabile Plattform zu bieten.

Support JUnit Lambda

JUnit dient der Gewährleistung von Softwarequalität. Ketzerisch lässt sich behaupten, dass die Qualität immer gegen Zeit und Budget verliert. So scheint es, dass Frameworks, die der Effizienzsteigerung dienen, häufig eine größere Lobby haben und von finanzkräftigen Unternehmen unterstützt werden. Diese dauerhafte Zuwendung ist JUnit aktuell nicht vergönnt, sodass das JUnit-Lambda Projekt-eine Crowdfunding-Kampagne gestartet hat, um die geplanten Erweiterungen umzusetzen. Mehr zu JUnit Lambda findet sich auf der Projektseite.

Geschrieben von
Dirk Dorsch
Dirk Dorsch
Dirk hat seit 2008 nahezu alle Rollen in der Java-basierten (mobile) Enterprise-Entwicklung durchgemacht. In den Jahren als Entwicklungsleiter vermisste er das Hands-on und legt nun den Fokus wieder auf die Entwicklung.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: