Vortrag auf der JAX 2017

1. Consumer-Driven Contract
Testing - ein Überblick_
Tobias Flohre
10.05.2017

2. Agenda_
Testing
Consumer-Driven Contract Testing - das Prinzip
PACT
Spring Cloud Contract
Gegenüberstellung / Fazit
2

3. Testpyramide_
Martin Fowler / Mike Cohn - Succeeding with Agile
3

4. Testpyramide_
4
Unit-Tests
Integration-Tests
End2End
Tests
JUnit
Mockito
JUnit
Spring TestContext
Arquillian
Selenium
Docker
Robot
Build-Job
Maven
Jenkins
Build-Job
Maven
Jenkins
Testumgebung
Maven
Jenkins

5. Testpyramide_
5
Unit-Tests
Integration-Tests
End2End
Tests

6. Testpyramide_
6
Unit-Tests
Integration-Tests

7. Verteilte Systeme und Testing_
7
Unit
Integration
Unit
Integration
Unit
Integration
Unit
Integration
Unit
Integration
End2End

8. 8
End2End
Verteilte Systeme und Testing_

9. 9
End2End
Verteilte Systeme und Testing_

10. 10
Consumer Driven Contracts - Das Prinzip_

11. Consumer Driven Contracts - Das Prinzip_
11

12. Consumer Driven Contracts - Das Prinzip_
12
Consumer
Provider

13. Consumer Driven Contracts - Das Prinzip_
13
Consumer
Provider
•Consumer erstellt Contract
• abgestimmte Syntax
•Provider implementiert Contract
•Contracts werden bei jedem Build geprüft
•Kommunikation!

14. 14
Consumer Driven Contracts - Das Prinzip_
•Fragen
• Wo werden die Contracts gespeichert?
• In welcher Form werden die Contracts gehalten?
• Wie werden die Contracts ausführbar gemacht?
• Was wird an Infrastruktur benötigt?
• Wie betten sich die Tests in die CI-/CD-Pipeline ein?
• Welche Art der Kommunikation kann ich so testen?

15. PACT_
15
Copyright © DiUS 2017

16. PACT_
16
Copyright © DiUS 2017

17. PACT_
17
•Zentrales Element: pact file
• beschreibt den Contract
• technologieunabhängig
{
"provider": {
"name": "MitarbeiterProvider"
},
"consumer": {
"name": "MitarbeiterConsumer"
},
"interactions": [{
"providerState": "mitarbeiter_geladen",
"description": "Ermittlung Mitarbeiter",
"request": {
"method": "GET",
"path": "/mitarbeiter"
},
"response": {
"status": 200,
"headers": {
"Content-Type": "application/json;charset=UTF-8"
},
"body": [{
"name": "Tobias"
}, {
"name": "Marcel"
}]
}
}],
"metadata": {
"pact-specification": {
"version": "2.0.0"
},
"pact-jvm": {
"version": "2.1.13"
}
}
}

18. PACT_
18
•Consumer generiert pact file
•Abhängig von der Sprache / Bibliothek
• sehr viele Implementierungen
•JVM: JUnit

19. PACT_
19

20. 20
•Consumer testet pact selbst
PACT_

21. 21
•Provider prüft den Contract anhand pact file
• sehr viele Implementierungen
•JVM
• Maven- / Gradle-Plugin
• JUnit
• Spring MVC
PACT_

22. 22
•Beispiel: Maven-Plugin - Konfiguration
• Referenz auf pact files
• Provider muss laufen
• mvn pact:verify
PACT_

23. 23
•Beispiel: Maven-Plugin - Konfiguration
• State Change URL
PACT_

24. 24
•Wie starten wir die Anwendung?
•Wie halten wir die pact files?
PACT_

25. 25
•Wie starten wir die Anwendung?
• Abhängigkeiten
• Testdaten / stateChangedUrl
• Job 1 baut
• Job 2 deployed in
Testumgebung
• Job 3 startet mvn pact:verify
• Job 1 baut
• Job 2 startet Anwendung lokal
(bspw. Spring Boot Maven Plugin)
• Job 2 führt das verify aus
• Job 2 stoppt Anwendung
PACT_

26. 26
•Wie halten wir die pact files?
• Pact Broker
• Dokumentation / Netzwerkdiagramme
• Tags (prod/dev)
• Webhooks
PACT_

27. PACT_
27
ProviderConsumer
2. build
PACT Broker
1. add contract
•Workflow Entwicklung Consumer
3. publish pact DEV
4. trigger provider verify DEV

28. PACT_
28
Provider
Consumer
2. build
PACT Broker
1. trigger release
•Workflow Release Consumer
3. publish pact PROD
4. trigger provider verify PROD
5. deploy if (4) successful

29. PACT_
29
Provider
2. build
PACT Broker
1. implement
•Workflow Entwicklung / Release Provider
3. verify pacts DEV
4. verify pacts PROD
5. deploy if (4) successful

30. Spring Cloud Contract_
30
•Basisfakten
• beschränkt auf JVM
• in erster Linie Spring
• kann auch Messaging
• klarer Workflow

31. Spring Cloud Contract_
31
lokal
Provider
Consumer
1. fork
Provider-Fork
2. add contract
•Workflow

32. Spring Cloud Contract - Groovy DSL_
32
package contracts
org.springframework.cloud.contract.spec.Contract.make {
request {
method 'PUT'
url '/fraudcheck'
body([
"client.id": $(regex('[0-9]{10}')),
loanAmount: 99999
])
headers {
contentType('application/json')
}
}
response {
status 200
body([
fraudCheckStatus: "FRAUD",
"rejection.reason": "Amount too high"
])
headers {
contentType('application/json')
}
}
}

33. Spring Cloud Contract_
33
lokal
Provider
Consumer
1. fork
Provider-Fork
2. add contract
3. publish stubs
locally
4. write tests
using stubs
•Workflow

34. 34
•Maven-Plugin generiert Stubs
• Wiremock-Stubs
• Stubs werden mit classifier -stubs in Maven Repo geladen
•Tests starten und verwenden Stubs
Spring Cloud Contract_

35. Spring Cloud Contract_
35
lokal
Provider
Consumer
1. fork
Provider-Fork
2. add contract
3. publish stubs
locally
4. write tests
using stubs
5. submit PR
6. write implementation
7. write test base class
8. build and publish stubs
•Workflow

36. 36
•Provider: Maven-Plugin generiert
Stubs und Tests
• Modi für Testgenerierung:
MockMvc, Explicit
• Tests erben von einer Basis-Klasse,
die selbst implementiert werden
muss -> Hier wird Infrastruktur
initialisiert
•Provider muss nicht laufen bei Ausführung der Tests!
Spring Cloud Contract_

37. Spring Cloud Contract_
37
lokal
Provider
Consumer
1. fork
Provider-Fork
2. add contract
3. publish stubs
locally
4. write tests
using stubs
5. submit PR
6. write implementation
7. write test base class
8. build and publish stubs
9. use stubs
•Workflow

38. 38
stubrunner:
repositoryRoot: https://nexus/demo/libs-release
•application yaml
•workOffline deaktivieren
Spring Cloud Contract_

39. Spring Cloud Contract_
39
lokal
Provider
Consumer
1. fork
Provider-Fork
2. add contract
3. publish stubs
locally
4. write tests
using stubs
5. submit PR
6. write implementation
7. write test base class
8. build and publish stubs
9. use stubs
•Workflow

40. 40
•Spring RestDocs zum Generieren der Contracts / Stubs
• Provider-driven
•pact files als Contract
Spring Cloud Contract_

41. Fazit_
41
•Einbindung in CI/CD ist elementar
• Continuous Deployment passt am besten
• Stark branch-basiertes Arbeiten hinderlich
•Spring Cloud Contract bietet etwas mehr im Messaging-
Bereich
•Pact ist technologie-unabhängig
•Pact: DSL wird im Consumer-Projekt verwendet
• Keine global verwendbaren Stubs
•SCC: DSL wird per Fork ins Provider-Projekt eingebracht
• Generierte Stubs mit Provider versioniert
• global verwendbar

42. 01
Fragen?
Tobias Flohre
codecentric AG
Hochstraße 11
42697 Solingen, Deutschland
www.codecentric.de
blog.codecentric.de
@tobiasflohre