Status Update

Logbuch JUnit Lambda: Zwischen Kickoff und Alpha kommt der Prototyp

Matthias Merdes, Dirk Dorsch

Mit dem JUnit-Lambda-Projekt hat sich eine Gruppe von Entwicklern um den langjährigen JUnit-4-Committer Marc Philipp das Ziel gesetzt, das nächste große Release 5 für das Java-Unit-Test-Framework JUnit zu schaffen.

Um die notwendigen finanziellen Mittel für eine fokussierte und zeitlich konzentrierte Arbeit an diesem Projekt zu garantieren, wurde im August 2015 auf Initiative von Johannes Link hin eine Crowdfunding-Kampagne gestartet. Diese Kampagne endete am 2. Oktober 2015 und brachte mit knapp 54.000 Euro mehr als das Doppelte des ursprünglich anvisierten Minimalbudgets. Während ein Teil des Teams für dieses neue Projekt von ihren Arbeitgebern freigestellt wird, sollen aus diesen Mitteln die selbständigen Entwickler innerhalb des Teams zumindest für die bei Tageslicht geleisteten Arbeitsstunden eine partielle Aufwandsentschädigung erhalten.

Alle Mittel, die bis zum für das zweite Halbjahr 2016 geplanten finalen Release nicht aufgebraucht wurden, werden einem gemeinnützigen Projekt gespendet. Die Verwendung der Mittel wird außerdem offengelegt, um eine größtmögliche Transparenz zu schaffen. Die Höhe des erreichten Betrags, aber auch die mit 474 hohe Zahl an Unterstützern, zeigt das große Interesse der Community an der Vision des JUnit-Lambda-Projektes. Neben 428 privaten Personen haben 36 Unternehmen, darunter große Anwender, insbesondere aber auch Hersteller von Entwicklungswerkzeugen, ihren Anteil zur Unterstützung beigetragen.

Kickoff

Vom 20. bis 22. Oktober fand das Kickoff-Meeting mit den Entwicklern des Projektes und einigen Vertretern der Sponsoren bei Andrena Objects in Karlsruhe statt. Da eine der wesentlichen Ideen des JUnit-Lambda-Projektes die Verbesserung der Integration von JUnit in Entwicklungswerkzeuge darstellt, waren neben dem Build-Tool-Hersteller Gradleware mit Eclipse und Intellij IDEA auch zwei der wichtigsten IDEs beim Anforderungsworkshop vertreten. Mit American Express, einem der Hauptsponsoren der Kampagne, war auch ein Anwender außerhalb der Softwareindustrie anwesend. Mit Pivotal, Hersteller des Spring-Frameworks, brachte als weiterer Hauptsponsor auch eines der ganz zentralen Softwareunternehmen im Java-Universum seine Anforderungen ein.

Ein wesentliches Ergebnis des Anforderungsworkshops ist die Konkretisierung der Anforderungen bezüglich der Tool-Integration von JUnit. Künftig sollen neue Versionen von JUnit einfacher und schneller in die entsprechenden Tools integriert werden können. Bei der Entwicklung von JUnit 5, a.k.a JUnit Lambda, wird auf Abwärtskompatibilität geachtet, um die unterschiedlichen Versionen von JUnit parallel einsetzen zu können, da im Allgemeinen nicht davon ausgegangen werden kann, dass große bestehende Testsuiten vollständig auf JUnit 5 portiert werden. Ein neue Gesamtarchitektur, die auf einer sauberen Trennung zwischen Programmiermodell (im wesentlichen Annotationen wie @Test), Launcher beziehungsweise Runner und verschiedenen Engines (zunächst für JUnit 4 und JUnit 5) basiert, soll die Integration von JUnit in Tools erheblich erleichtern. Beim Extension-Modell liegt der Fokus vor allem auf der Komponierbarkeit von Erweiterungen. In JUnit 4 ließen sich alternative Runner nicht kombinieren, selbst wenn sie technisch orthogonale Belange behandelten.

Die Wichtigkeit des Themas Integrierbarkeit wird auch dadurch deutlich, dass parallel zum Prototypen bereits Integrationen für Gradle und Maven/Surefire sowie ein JUnit-4-Runner entwickelt werden, welche die Ausführung von JUnit-5-Tests in vorhandenen JUnit-4-Infrastrukturen erlaubt.

Eine erste prototypische Integration des weit verbreiteten Mockito-Frameworks demonstriert neue Möglichkeiten der Erweiterung des JUnit-5-Kerns.

Mit der Open Test Alliance (OTA4J) reiften erste Überlegungen für eine allgemeine Definition von Exception-Schnittstellen für Werkzeuge aus dem Testbereich. Vorrangiges Ziel ist es, dass alle Testframeworks für die JVM wie JUnit, TestNG oder Spock, sowie Assertion-Bibliotheken wie Hamcrest oder AssertJ ein gemeinsames Set von Exceptions verwenden können. Bisher war hier der einzige Integrationspunkt java.lang.AssertionError. Eine einheitliche Kommunikation z.B. von Mehrfachfehlern, übersprungenen oder abgebrochenen Tests war nicht möglich. Auf diese Weise wird es für IDEs und Build-Tools möglich, spezifischere Fehlersituationen konsistent zu unterstützen. Die einheitliche Spezifikation von Exceptions entkoppelt die Tools von den Bibliotheken und vereinfacht so die Implementierung, beispielsweise von Reportings. Die Notizen aus dem Kickoff-Meeting in Abbildung 1 zeigen die Notwendigkeit einer solchen Abstraktion, da offensichtlich stark unterschiedliche Vorgehen implementiert sind.

 

abbildung1

Abb. 1: Interpretation der Assertions in Eclipse und IntelliJ

Über die Bedürfnisse der Toolintegration hinaus werden natürlich vor allem die Entwickler bedient. Das letzte große Release von JUnit war Version 4 und ist 10 Jahre her. Seitdem haben sich einerseits viele neue Ideen angesammelt, andrerseits haben sich manche bestehende Konstrukte im Bereich der Erweiterbarkeit als nicht optimal erwiesen. Auch an einer technisch ausgezeichneten und bewährten Lösung wie JUnit 4 nagt eben der Zahn der Zeit. Unter anderem ist ein zeitgemäßeres Programmiermodell vorgesehen, im aktuellen Prototyp können Testnamen beispielsweise Emoticons enthalten. Eine dynamische Test-Registrierung soll die Ausführung generativer Tests ermöglichen. Bereits im aktuellen Prototypen ist es möglich, Testmethoden mit Argumenten zu definieren, deren Werte zur Laufzeit typ- oder annotationsbasiert von der Ablaufinfrastruktur oder von Erweiterungen injiziert werden. Dieses mächtige Feature ist vielen Spring-Entwicklern von den flexiblen Signaturen bei Spring-Controller-Klassen bekannt.

Listing 1 zeigt, wie mit Lambdas neue Sprachkonzepte aus Java 8 eingesetzt werden können, um ein elegantes Testen von Exceptions zu ermöglichen.

assertThrows(IllegalArgumentException.class,() -> {
	causeAnException();
});	

IllegalArgumentException	expected =
	expectThrows(IllegalArgumentException.class,	() -> {
		causeAnException();
});
	assertThat(excepted).hasMessage("bla");

Eine bedingte Testausführung und aggregierte Assertions bieten darüber hinaus weitere neue Möglichkeiten in der Testentwicklung. Abbildung 2 zeigt, welche weiteren Themen und Anforderungen neben diesen im Kickoff Workshop diskutiert wurden.

abbildung2

Abb. 2: Gesammelte Anforderungen

 

Der Projektplan

Das Kickoff Meeting wurde nicht nur zu einer intensiven Anforderungsaufnahme genutzt, es ging unmittelbar in die Prototyping-Phase über. Erste Ergebnisse können im Github Repository des Projektes mitverfolgt werden. Die Notizen aus Abbildung 3 und 4 zeigen den für den Prototyp geplanten Scope. Für die kommende Projektphase bittet das Team mit einem „Request for Feedback“ um Rückmeldungen zum Stand des Prototyps. Hierbei soll insbesondere Feedback zum angedachten Programmiermodell sowie der APIs und SPIs abgegeben werden.

abbildung3

Abb. 3: Geplanter Scope des Prototyps

 

abbildung4

Abb. 4: Geplanter Scope des Prototyps

Im Anschluss an das Prototyping geht das Projekt ab dem 30. November in die dritte Phase. Ziel ist es, in einem erneut zweiwöchigen Meetup des Teams die Erkenntnisse der Prototyping-Phase und das Community-Feedback aufzubereiten und mit den Arbeiten für ein „echtes Produkt“ zu beginnen. Für Februar 2016 ist dann ein erstes Alpha-Release geplant. Mit diesem Alpha-Release wird erneut Feedback der Community eingeholt, um dieses in einigen weiteren Iterationen zu verarbeiten. Für den Sommer 2016 ist ein Beta-Release geplant, das im Herbst auf einer (Beta-)Release Party gefeiert werden soll.

Verwandte Themen:

Geschrieben von
Matthias Merdes
Matthias Merdes
Matthias Merdes ist Lead Developer Architecture and Services bei der Heidelberg Mobil International GmbH, einem der Hauptsponsoren von JUnit Lambda. Er befasst sich seit JDK 1.1 mit Java-Technologien vor allem im Backend-Bereich und ist begeisterter Groovy-Programmierer. Allgemein interessiert sich Matthias für alle Technologien, die Enterprise Development einfacher, eleganter und effizienter machen.
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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.