JUnit 5 Design und Architektur eines Frameworks

Transkript

1 JUnit 5 Design und Architektur eines Frameworks

2 @johanneslink johanneslink.net

3 Softwaretherapeut "In Deutschland ist die Bezeichnung Therapeut allein oder ergänzt mit bestimmten Begriffen gesetzlich nicht geschützt und daher kein Hinweis auf ein erfolgreich abgeschlossenes Studium oder auch nur fachliche Kompetenz." Quelle: Wikipedia

4 JUnit 5 Initiator - zusammen mit Marc Philipp - und Core-Committer im ersten Jahr jqwik: Externe JUnit5-Test-Engine für Property- Based Testing

5 themenübersicht JUnit 5: Vision einer Plattform Architektur der Plattform Wie gut funktioniert die Vision? Extensibility: Zwei Ansätze im Vergleich

6 Warum braucht die Welt ein neues JUnit?

7

8 A Brief History of JUnit Runner Rules 2015 JUnit Lambda Campaign 2017 JUnit 5.0.0

9

10 Wartbarkeit beta-1

11

12 JUnit 4 "Architektur"

13 Erfolg von JUnit 4 als Plattform verhindert Weiterentwicklung von JUnit 4 als Werkzeug!

14 JUnit-5 Design-Ziel Trennung der Aspekte JUnit als Testwerkzeug und JUnit als Plattform JUnit 4 und 5 nebeneinander, um Adaption und Migration zu erleichtern

15 DIY Architecture: Step by Step

16 Allgemein erwünschte Eigenschaften eines Frameworks Usability Separation of Concerns Freie Kombinierbarkeit mit anderen Frameworks und Bibliotheken Erweiterbarkeit Abwärts- und Aufwärtskompatibilität Keine oder wenig Abhängigkeiten

17 Schritt 1: Trennung von Framework- Nutzung und Framework-Anbindern Nutzung (API): IDE: Anzeigen, Auswahl und Anstoßen von Tests Programmierer: Schreiben/Spezifizieren von Tests Anbinder (SPI) Interpretation von Testspezifikationen

18 junit-platform-launcher junit-platform-engine Launcher TestPlan discover(discoveryrequest) void execute(testplan) <<interface>> TestEngine discover() void execute() junit-jupiter JupiterTestEngine myproject test1

19 Trennung von Entdecken und Ausführen

20 Trennung von Entdecken und Ausführen

21 Schritt 2: Ständiger Fortschrittsbericht eines Testlaufs Events / Nachrichten statt Rückgabe eines Ergebnisses

22 TestEngine execute(request) ExecutionRequest <<interface>> TestDescriptor <<interface>> EngineExecutionListener void executionstarted(testdescriptor) void executionfinished(testdescriptor, result) children TestExecutionResult <<enum>> Throwable Status Successful Failed Aborted

23

24 Execution Listener

25 Schritt 3: Gleichzeitiger Einsatz mehrerer Test-Engines Jede Test-Engine hat ihre eigene API zur Testfallspezifikation Sevice-Provider-Mechanismus von Java zur Registrierung einer Test-Engine

26 junit-platform-launcher ServiceLoaderTestEngineRegistry Launcher TestPlan discover(discoveryrequest) void execute(testplan) junit-platform-engine <<interface>> TestEngine discover() void execute() junit-jupiter-api <<annotation>> org.junit.jupiter.api.test create junit-jupiter-engine JupiterTestEngine junit-vintage-engine myproject VintageTestEngine test1 test1 junit-4.12 <<annotation>> org.junit.test

27 Schritt 4: Leichte Serialisierbarkeit aller SPI-Objekte Notwendig um Inter-Prozess-Kommunikation zur ermöglichen UniqueId als verbindendes Element TestDescriptor vs Testidentifier und TestPlan

28 junit-platform-launcher TestPlan Set<TestIdentifier> getroots(identifier) Set<TestIdentifier> getchildren(identifier) Optional<TestIdentifier> getparent(identifier) <<interface>> TestExecutionListener executionstarted(testidentifier) identifiers <<immutable>> ExecutionListenerAdapter TestIdentifier <<interface>> TestDescriptor <<immutable>> UniqueId UniqueId append(type, value) children AbstractTestDescriptor <<immutable>> Segment String type String value segments <<interface>> EngineExecutionListener executionstarted(testdescriptor) junit-platform-engine

29 VINTAGE JUPITER THIRD PARTY PLATFORM

30 THIRD PARTY JUPITER VINTAGE PLATFORM

31 Andere Architekturaspekte API Lifecycle-Management mit Mögliche Status: Stable, Maintained, Experimental, Deprecated, Internal Test auf Zyklenfreiheit mit degraph Strikte Formattierungsregeln via checkstyle

32 Platform Usability Test-Engines nutzen und selbst entwickeln

33 Warum braucht die Welt mehr als zwei Test-Engines? Andere JVM-Sprache Anderes Spezifikationsmodell Anderes Ausführungsmodell Für Erweiterungen des Test-Modells genügt häufig eine Jupiter-Extension

34 Test-Engine benutzen 1. TestCompile-Dependency hinzufügen: org.myorg:my-engine:x.y.z 2. Tests schreiben

35 Test-Engine benutzen 1. TestCompile-Dependency hinzufügen: org.myorg:my-engine:x.y.z org.junit.jupiter:junit-jupiter-engine: Tests schreiben

36 Test-Engine Kochrezept 1. Compile-Dependencies hinzufügen 2. TestEngine-Interface implementieren 3. Engine registrieren 4. Tests in IDE starten

37 DEMO Die kleinste Test-Engine der Welt

38 git clone cd jax2017/empty-engine/ gradle test

39 dependencies { compile("org.junit.platform:junit-platform-engine:1.0.0 ) compile("org.junit.platform:junit-platform-commons:1.0.0") // For writing integration tests testcompile("org.junit.platform:junit-platform-launcher:1.0.0") } // Only necessary to enable IntelliJ support testruntime("org.junit.jupiter:junit-jupiter-engine:5.0.0")

40 Test-Engine registrieren /META-INF/services/ org.junit.platform.engine.testengine nano.nanoengine

41

42 TestEngine-Interface implementieren 1. Create TestEngine class 2. Implement discover() 3. Implement execute()

43 Was fehlt zu stärkerer Test-Engine? Nano kann von IDE ausgeführt werden, aber ist sehr beschränkt Test-Spezifikation durch Klassen und Methoden

44 public class A_tiny_test { final int theanswer = 42; public boolean this_should_return_true() { } return theanswer == 42; public boolean this_returns_false() { return theanswer == 43; } }

45

46

47 Tests in IDE identifizieren Theoretisch ist jedes zur Laufzeit ermittelbare Spezifikationsmodell umsetzbar Aber: Alles immer zu kompilieren ist für (manche) IDEs nicht realisierbar <<annotation>> org.junit.platform.commons.annotation.testable Meta-Annotation <<annotation>> org.junit.jupiter.api.test <<annotation>> TinyTest

48 Was geht noch? Ausführen von Dateien, URLs, und anderen Ressourcen jqwik.net: Property Testen in Java Specsy: Alles mit Lambdas Wrapper für Cucumber, Spock, Fitnesse etc

49 Tool-Support: State of the Union erforderlich für Run-Symbol am Source-Code Gezielter Teststart nur für Klasse/Methode/Package und andere Unstimmigkeiten Eclipse Geplant für Gradle und Maven vom JUnit-Team gepflegt

50 Architekturbewertung der JUnit-5-Plattform git clone

51

52 Bewertungskriterien Usability Separation of Concerns Freie Kombinierbarkeit mit anderen Frameworks und Bibliotheken Erweiterbarkeit Auf- und Abwärtskompatibilität

53 JUnit 5 Architektur: Usability Für den Engine-Verwender denkbar einfach Für den Engine-Entwickler Einfache Schnittstellen IDE- und Build-Support bekommt man umsonst Viel Logik (Discovery + Execution) muss selbst implementiert werden - Support-Packages für Reflection, Classpath-Scanning, Exception- Handling und Hierarchische Testspecs

54 JUnit 5 Architektur: Separation of Concerns Gute Trennung von APIs, SPIs, Runnern, Engines, Build-Support Aber: Komplizierte Abhängigkeitsstruktur in Build-Files

55 JUnit 5 Architektur: Kombinierbarkeit mit anderen Frameworks Kaum Abhängigkeiten, dadurch kaum Konfliktpotenzial Aber: Die Plattform übernimmt den kompletten Ausführungslebenszyklus

56 JUnit 5 Architektur: Erweiterbarkeit Engines sind völlig unabhängig voneinander und frei miteinander kombinierbar Aber: Funktionalitätssharing zwischen Engines nicht vorgesehen

57 JUnit 5 Architektur: Auf- und Abwärtskompatibilität 99,9 % abwärtskompatibel mit JUnit 4.12 API Annotationen unterstützen bei der sinnvollen API-Nutzung Aber: Stabilität der API muss sich noch beweisen

58 Extensibility: Zwei Ansätze JUnit 4: Test-Runner: Übernimmt die komplette Testausführung Rules: Generic Statement Wrapping JUnit 5 Jupiter: Specialized Extension Points

59 JUnit 4 Statement Statement abstract void evaluate() throws Throwable class BlockJUnit4ClassRunner protected Statement methodblock(frameworkmethod method) { Object test; try { test = new ReflectiveCallable() protected Object runreflectivecall() throws Throwable { return createtest(); } }.run(); } catch (Throwable e) { return new Fail(e); } } Statement statement = methodinvoker(method, test); statement = possiblyexpectingexceptions(method, test, statement); statement = withpotentialtimeout(method, test, statement); statement = withbefores(method, test, statement); statement = withafters(method, test, statement); statement = withrules(method, test, statement); return statement;

60 JUnit 4 Rule <<interface>> TestRule Statement apply(statement) public class MyRule implements TestRule public Statement apply(final Statement base) { return new Statement() public void evaluate() throws Throwable { public class public MyRule myrule = new public void atest() { } } } } } }; // Do something before standard behaviour base.evaluate(); // Do something after standard behaviour

61 Vor- und Nachteile? + Einfache Abstraktion + Einfache Komponierbarkeit - Nur von Innen nach Außen komponierbar - Keine Möglichkeit die Schachtelung zu verändern - Seiteneffekte zwischen Rules nicht kontrollierbar

62 Jupiter Extension API

63 Jupiter Extensions

64 Jupiter Callbacks <<interface>> Extension <<interface>> BeforeEachCallback void beforeeach(extensioncontext)

65

66 Test Lifecycle Callbacks Conditional Execution Allgemeine Extensions BeforeAllCallback ContainerExecutionCondition ParameterResolver BeforeEachCallback TestExecutionCondition TestExecutionExceptionHandler BeforeTestExecutionCallback TestInstancePostProcessor AfterTestExecutionCallback AfterEachCallback AfterAllCallback

67

68 Extensions sind Komponierbar Zustandslos Können Zustand über einen Store transportieren und austauschen Namespaces Hierarchisch

69 Beispiel: Mockito-Extension public class MockitoExtension implements TestInstancePostProcessor, ParameterResolver public void postprocesstestinstance(object testinstance, ExtensionContext context) { MockitoAnnotations.initMocks(testInstance); public boolean supportsparameter(parametercontext parametercontext, ExtensionContext extensioncontext) { return parametercontext.getparameter().isannotationpresent(mock.class); public Object resolveparameter(parametercontext parametercontext, ExtensionContext extensioncontext) { return getmock(parametercontext.getparameter(), extensioncontext); } private Object getmock(parameter parameter, ExtensionContext extensioncontext) { Class<?> mocktype = parameter.gettype(); Store mocks = extensioncontext.getstore(namespace.create(mockitoextension.class, mocktype)); } } return mocks.getorcomputeifabsent(mocktype.getcanonicalname(), key -> mock(mocktype));

70 Beispiel: Spring-Extension public class SpringExtension implements BeforeAllCallback, AfterAllCallback, TestInstancePostProcessor, BeforeEachCallback, AfterEachCallback, ParameterResolver

71 Vor- und Nachteile? + Feingranulare Eingriffe in den Lebenszyklus möglich + Gute Komponierbarkeit unterschiedlicher Extensions + State nur wenn nötig - Zahlreiche unterschiedliche Callbacks notwendig - Komplexer Life-Cycle in der Testausführung - Nicht alle unerwünschten Interaktionen zwischen Extensions sind kontrollierbar

72 Links Artikel über JUnit-5-Architektur Artikel über Jupiter-Extension-Modell Framework Design Principles: JUnit 5: Jqwik-Engine: