TDD. Herzblut. Zukunft. Java. JUnit 5. Namics....5.0.0-ALPHA 10 11 12 JUNIT LAMBDA – WIE ALLES...

TDD. Herzblut. Zukunft. Java. JUnit 5. Namics.

FRANKFURT, 26. APRIL 2016

Stefan Bechtold. Software Craftsman.

Agenda.

ERSTENS Namics in a Nutshell. 5 MIN

ZWEITENS JUnit Lambda – wie alles begann 10 MIN

DRITTENS JUnit 5 – Framework 10 MIN

V IERTENS JUnit 5 – Programmiermodell 25 MIN

FÜNFTENS Fragen & Diskussion 10 MIN

Namics in a nutshell. ERSTENS

HYBRIS. E-COMMERCE. TECHNICAL ARCHITECTURE.

Frankfurt Technologie E-Commerce

Kompetenzen _  Hybris Certified Core & Commerce Developer _  iSAQB Certified Professional for Software Architecture _  Sun Certified Java Programmer _  Programmiersprachen: Java (SE/EE), C#, C/C++, Objective-C _  Web-Technologien: AJAX, CSS, JavaScript, XSLT

Ausgewählte Open Source Projekte _  JUnit 5 Committer (Core Team) _  Erfinder des JUnit 4 - Hierarchical Context Runner

Ausgewählte Namics Projekte _  Kaufland: Technische Leitung, Konzeption und Implementierung

für SAP Hybris & Adobe AEM, sowie System-Integration in SAP _  BAUHAUS AG: Technische Leitung, Konzeption und

Implementierung für SAP Hybris, u.a. Preisberechnung, Performanceanalysen und -optimierungen Stefan Bechtold.

Software Craftsman.

Print version

Hybris

Namics. NAMICS IN A NUTSHELL

Full Service. Nah dran. Namics. 5

à NAMICS IN A NUTSHELL 500 6

20 C

T K

Full-Service.

Expertise.

Dynamisch.

Begleitung auf Augenhöhe.

Mutig.

Ergebnisqualität.

Kundenzufriedenheit.

JUnit Lambda - wie alles begann ZWEITENS

Namics. 14 JUNIT LAMBDA – WIE ALLES BEGANN

Warum braucht es ein neues JUnit?

-  JUnit 4 wurde im Februar 2006 released

-  Seitdem: -  Sehr viele Veränderungen im Framework -  Das Testing hat sich weiterentwickelt -  Erwartungen an das Testing sind gestiegen

-  Erwartungen werden nicht mehr erfüllt

-  Wartung & Erweiterung sehr zeitintensiv


JUnit 4 – Pain points

Modulariät !?

-  Packages: Ja, aber nur ein junit.jar Modul



JUnit 4 Runner API

-  Sehr mächtiges Konzept

-  Öffnet Tor und Türen für Erweiterungen

-  Aber: Runner sind nicht kombinierbar ! -  Negativ-Beispiel: -  Parameterized -  SpringJUnit4ClassRunner



JUnit 4 Rules

-  Neuer Erweiterungsmechanismus seit JUnit 4.7

-  Wrapper um Ausführung auf verschiedenen Ebenen -  eines Tests (@Rule) -  einer Testklasse (@ClassRule)

-  Sehr gute Kombinierbarkeit

-  Aber: Mächtigkeit oft nicht genug, um Ausführung übergreifend zu beeinflussen (z.B. Spring)


JUnit Lambda – Rise of a new star


JUnit Lambda

Crowdfunding Kampagne

-  Kern Team -  Marc Philipp (JUnit 4 Committer), Johannes Link -  Matthias Merdes, Sam Brannen, Stefan Bechtold

-  Kampagne lief von Juli bis Oktober 2015

-  Ergebnis: 53.937,- € (von 474 Personen & Firmen)

-  4 Firmen spendierten als Hauptsponsoren zusätzlich jeweils 6 Wochen Entwicklungszeit


DANKE !


JUnit Lambda – Kick Off Meeting

Vertreter wichtiger Build Tools, IDEs, Sponsoren, das JUnit 5 Kern Team


JUnit Lambda – Prototype

-  Ziele: -  Proof of Concept erster Ideen aus dem Kick Off Meeting -  Lauffähiger Prototype als Basis für Feedback -  Feedback aus der Community einholen

-  Beginn: Direkt nach dem Kick Off Meeting

-  Ende: 02. Dezember 2015


JUnit Lambda – Alpha Release

-  Ziele: -  Feedback aus der Community einbeziehen -  Lessons Learned aus der Prototype Phase -  Größtenteils Neuimplementierung

-  Beginn: Mitte Dezember 2015

-  Ende: 01. Februar 2016

Namics.

J

Uni

t 5

A

lpha

PoC

2015 07

…

10

11 12 2016

01 02 03 04 05 06 07 08 09

10 11 12

JUNIT LAMBDA – WIE ALLES BEGANN

JUnit Lambda – Road Map (geplant) 24

Kampagne

Setup & Kick Off

Prototype PoC

Development 5.0.0-ALPHA

5.0.0-M1 5.0.0-M2 5.0.0-M3 Development RC1 RC2 5.0.0

JUnit Framework

DRITTENS

Namics. 26 JUNIT 5 FRAMEWORK

JUnit 5 in a Nutshell

-  Modular

-  Erweiterbar

-  Zeitgemäß

-  Auf- und abwärtskompatibel -  JUnit 5 unterstützt JUnit 3.8 und 4 -  JUnit 5 ist von JUnit 4 ausführbar *

* mit kleineren Einschränkungen

Namics.

•  Modularer Aufbau

•  Test Code hängt nur von junit5-api ab

•  IDEs und Build Tools verwenden

ausschließlich Launcher und Engine

APIs und können Tests unabhängig vom

benutzten Testing Framework ausführen

Architektur JUNIT 5 FRAMEWORK 27

Namics.

•  Zentraler Startpunkt für alle Clients (IDEs, Build Tools, etc.)

•  Eindeutige API für das Auffinden und

die Ausführung von Tests aller Engines

•  TestDiscoveryRequest für die Selektion und Filterung

•  Informationen & Feedback über die

TestExecutionListener API

Launcher API JUNIT 5 FRAMEWORK 28

Namics.

•  Test Engines ermöglichen das Auffinden und Ausführen von Tests eines

bestimmten Programmiermodells

•  Test Engines werden zur Laufzeit mittels

ServiceLoader API ermittelt

•  Stellt ein Testing Framework eine

TestEngine-Implementierung bereit,

kann es über die Launcher API

aufgerufen werden

Engine API JUNIT 5 FRAMEWORK 29

Namics.

•  Alle öffentlichen Klassen sind mit der @API-Annotation versehen

•  Die “Usage” gibt an, ob eine Klasse für

die Verwendung von außen gedacht ist

und, falls ja, wie stabil diese ist

•  Mögliche Werte: Deprecated, Internal,

Experimental, Maintained, Stable

@API(Usage) JUNIT 5 FRAMEWORK 30

Namics.

•  BeforeAllExtensionPoint

•  BeforeEachExtensionPoint

•  AfterEachExtensionPoint

•  AfterAllExtensionPoint

•  ContainerExecutionCondition

•  TextExecutionCondition

•  InstancePostProcessor

•  MethodParameterResolver

•  ExceptionHandlerExtensionPoint

JUnit 5 - Extensions JUNIT 5 FRAMEWORK 31

Namics. 32 JUNIT 5 FRAMEWORK

JUnit 5 - Extensions

Extensions können auf 2 Wege registriert werden

-  Deklarativ: @ExtendWith(Extension) -  Extension definiert ExtensionPoints durch ihren Type

-  Programmatisch: -  ExtensionRegistrar.registerExtensions(registry) -  ExtensionRegistrar wird mittels @ExtendWith registriert

JUnit Programmiermodell

VIERTENS

Namics. 34

JUnit 5 - Programmiermodell

-  Sichtbarkeit -  Annotations und Meta-Annotations -  Nested Test Classes -  Conditional Test Execution -  Custom Display Names -  Tagging -  Assertions und Assumptions -  Dependency Injection für Methoden -  Interface Default Methoden

Namics. 35 JUNIT 5 - PROGRAMMIERMODELL

Sichtbarkeit

-  JUnit 5 (er-)kennt Package Private! -  Sowohl Klassen als auch Methoden

-  “public” Keyword muss nicht mehr genutzt werden

-  Beispiel: FirstJUnit5Tests in User Guide


Annotations und Meta-Annotations

-  @Test -  @BeforeAll / @AfterAll -  @BeforeEach / @AfterEach

-  @DisplayName -  @Tag / @Tags -  @Disabled

-  @Nested

-  Meta-Annotations -  Erlauben die Bildung von

Custom Tags -  Analog zu Spring -  Später mehr bei Tags


Conditional Test Execution

-  Extensions treffen auf das Programmiermodell -  ContainerExecutionCondition -  TestExecutionCondition

-  @Disabled = DisabledCondition -  “Eating our own dog food” ;-)

-  Hinweis: Löst @Ignore vollständig ab!


Custom Display Names

-  Standard-Namen unverändert -  Name der Test-Klasse -  Name der Test-Methode

-  Neu: @DisplayName -  Anwendbar auf Klassen und Methoden -  Unterstützt vollen UTF-8 Zeichensatz -  Sonderzeichen und sogar Emoji J


Nested Test Classes

-  Ermöglicht Gruppierung von Tests -  logisch und hierarchisch -  vgl. JUnit 4 – HierarchicalContextRunner

-  Initialisierung der äußeren Klasse wird durchlaufen

-  Beispiel: TestingAStack in User Guide


Tagging

-  Nützlich zur -  Kategorisierung von Tests -  Gruppierung von Tests -  etc.

-  Frei definierbar auf Basis von -  Klassen: Gültigkeit für alle Tests innerhalb -  Methoden: Gültigkeit für einen Test


Assertions

org.junit.gen5.api.Assertions

-  Unterstützt einfache Assertions -  assertTrue(), assertFalse(), assertEquals(), etc. -  assertThrows() / expectThrows() -  assertAll()

-  Supplier<String> für Fehlermeldungen

-  Für aufwändigere Assertions sollte ein Framework zum Einsatz kommen: AssertJ, Hamcrest, etc.


Assumptions

org.junit.gen5.api.Assumptions

-  Unterstützt einfache Annahmen zum Test-Abbruch -  assumeTrue(), assumeFalse() -  assumeThat()

-  Supplier<Boolean> zur Verifikation der Annahmen

-  Supplier<String> für Fehlermeldungen


Dependency Injection für Methoden

-  Extensions treffen auf das Programmiermodell -  MethodParameterResolver Extension

-  TestInfo: Innerhalb von @Test, @BeforeEach, etc. -  TestInfoParameterResolver -  “Eating our own dog food” ;-)

-  Beispiele: -  TestReporter, MockitoExtension, SpringExtension


Interface Default Methoden

-  Ermöglicht die Mehrfachvererbung für Tests

-  Unterstützung für -  @Test -  @BeforeEach -  @AfterEach

-  Erlaubt das Testen von Traits / Querschnittsthemen -  Sortierung, Vergleiche, etc.

-  Beispiel: StringTests in User Guide

Fragen & Diskussion FÜNFTENS

Namics. 46 FRAGEN & DISKUSSION

Was ist noch in der Pipeline?

-  Echte Integration in IDEs und Build Tools

-  Dynamische Tests -  (Registrierung via: Lambdas, Streams, Collections, etc.)

-  Parametrisierte Tests

-  Szenario Testing -  Vordefinierte Reihenfolge der Test Methoden

-  Parallelisierung der Testausführung

-  … (more to come)

Namics. 47 FRAGEN & DISKUSSION

Ressourcen / Feedback

-  Homepage: http://junit.org/junit5

-  User Guide: http://junit.org/junit5/docs/current/user-guide/

-  GitHub: https://github.com/junit-team/junit5

-  Samples: https://github.com/junit-team/junit5-samples

-  Twitter: https://twitter.com/junitteam

-  Stack Overflow: http://stackoverflow.com/tags/junit5

TDD. Herzblut. Zukunft. Java. JUnit 5. Namics....5.0.0-ALPHA 10 11 12 JUNIT LAMBDA – WIE ALLES...

Documents

Transcript of TDD. Herzblut. Zukunft. Java. JUnit 5. Namics....5.0.0-ALPHA 10 11 12 JUNIT LAMBDA – WIE ALLES...