Consumer-driven Contract Testing

In einer Microservices-Architektur entstehen viele Services, potenziell sogar in den verschiedensten Programmiersprachen. Um eine reibungslose Kommunikation zwischen diesen zu gewährleisten, müssen die Schnittstellen "passen". (Consumer-Driven) Contracts stellen einen Ansatz dar, der die Schnittstellen und zusätzlich deren Aufrufer (Clients) testet.
Verschiedene Probleme können so konkret adressiert werden. Zum Beispiel, dass in bestimmten Staging-Umgebungen oder aufgrund von Wartungen einzelne Provider zum Testzeitpunkt nicht zur Verfügung stehen und somit nicht live angesprochen werden können.
Wir stellen vor, wie Contract Based-Testing sich gegenüber anderen Teststufen einordnet, wie das Contract Testing-Framework PACT funktioniert und wie wir das Verfahren bei Hermes einsetzen.

Transcript

1. Consumer-driven Contract Testing Java User Group Hamburg Benjamin Baum, Hermes Germany Stephan Stapel, Hermes Germany Hamburg, 01.11.2018
2. Stephan Stapel Head of Customer Solutions Benjamin Baum Software Developer
3. Inhalt 01 Warum CDCT und was ist das eigentlich? 02 Tools für CDCT 03 Zwischen-Fazit 04 Implementierung von CDCT
4. 01 Warum CDCT und was ist das eigentlich?
5. Hermes Germany ist der zweitgrößte Paket-Logistiker Deutschlands. • Wir stellen derzeit etwa 400 Millionen Pakete pro Jahr zu. • Es gibt etwa 4 große Paket-Logistiker am deutschen Markt. • IT ist für uns ein Differenzierungsmerkmal.
6. Es gibt so gut wie keine Standard-Software für unser Umfeld. • Fokus auf Eigenentwicklungen • Mittelgroße Systeme • Micro Services • Viel gleichzeitige Bewegung
7. Unsere Anwendungslandschaft ist eng verwoben. • Viele Schnittstellen • Ansatz zur Vertikalisierung (Micro Services) • Ansatz, gezielt Backend-Services zu definieren, die von vielen Nutzern verwendet werden (SOA/ API)
8. Continuous Delivery hilft den Teams, die Zyklen zu verkürzen. Die Abstimmung zwischen den Teams wird so zum nächstgroßen Bottleneck. E2E- Tests Integrations- Tests Funktions-Tests/ Modul- Tests Fokus für heute
9. Die Abhängigkeiten stehen einer kontinuierlichen Lieferung im Weg. Diskussion der Schnittstelle Implementierung der Funktionalität Implementierung der Funktionalität Implementierung des Aufrufs End2End- Tests Team 1 Deployment Deployment Team 2 Synchronisation der Teams notwendig Synchronisation der Teams notwendig t t Implementierung der Schnittstelle ist meist schwer zeitlich zu synchronisieren. Ergebnis: Wartezeiten
10. End2End-Tests sind in realen Entwicklungen meist noch umfangreicher. Dank Micro Service-Architekturen gilt dies mehr nicht nur für große Anwendungslandschaften. 10 Implementierung Team 1 Team 2 Test End2End- Test Implementierung Test Implementierung Team 3 Test Implementierung Team 4 Test Implementierung Team n Test …
11. Die Abstimmung zwischen den Teams sollte auf mehreren Ebenen geschehen. 11 Gemeinsame Roadmap Effekt: Abhängigkeiten werden identifiziert und Arbeitspakete grob in zeitliche Reihenfolge gebracht. Planung Architektur Umsetzung (Dev & Test) myhermes Microservice Microservice Microservice Microservice CCM Microservice Microservice Microservice Microservice Architektur Vertikalisierung soweit wie möglich Effekt: Kleine Deployment-Einheiten ermöglichen Isolierung von Veränderungen Consumer Provider Technik Consumer-driven Contract Tests als Unterstützung der Abstimmung von Schnittstellen.
12. Wir nutzen Contracts, um die Beziehung zwischen Schnittstellenpartnern zu gestalten. 12 Consumer Provider Wir verwenden das Verfahren aktuell für (REST) Web Services. Die Nutzung ist auch für Messaging möglich.
13. Die typische Testpyramide E2E- Tests Integrations- Tests Funktions-Tests/ Modul-Tests • Scope umfassender • Aussagekraft über die Gesamtqualität höher • Feedback-Geschwindigkeit höher • Reaktionsmöglichkeit besser
14. Der Contract als Erwartung des Consumers an den Provider 14 Consumer Provider 1 Tests Tests Mock Provider 2 Mock Consumer 2 Der Contract fungiert als Unterstützung zur Abstimmung zwischen den Teams.
15. Begrifflichkeiten CBT CDC Consumer-driven Contracts Paradigma, dass Integration ausgehend vom Nutzer gestaltet wird. Contract-based Testing Das konkrete Vorgehen für Integrations-Tests. CDCT Consumer-driven Contract Testing Fasst beides zusammen: Contracts werden auf Basis des Nutzungsverhalten geschlossen, Integrations-Tests erfolgt anhand der Contracts.
16. Integrations-Tests ohne Integration E2E- Tests Integrations- Tests Funktions-Tests/ Modul- Tests • Integrations-Tests lokal pro Team. • Dadurch sind jeweils einzelne Services im Scope. • Alle Schnittstellen-Partner werden gemocked oder gestubbed.
17. Consumer Driven Contract Tests versetzen uns in die Lage, Integrations-Tests zu isolieren. 17 Provider Provider 3 Provider 2 Consumer Nutzer-bezogene Tests Anbieter-bezogene Tests Isolation gegenüber Dritt-Komponenten Isolation gegenüber Dritt-Komponenten
18. E2E- Tests Integrations- Tests Funktions-Tests/ Modul- Tests Effekte des Vorgehens • Integrations-Test „günstig“ – daher früh im Entwicklungsprozess möglich • Fehler werden schnell identifiziert und korrigiert • Roundtrip über Contract-Anpassung noch spät möglich • Scope von End2End-Tests kann deutlich geschärft werden
19. Die Vereinbarung des Kontraktes Diskussion der Schnittstelle und Kontrakt- Erstellung Implementierung der Funktionalität inklusive Aufruf und Integrations-Tests Implementierung der Funktionalität inklusive Integrations-Tests Team 1 Deployment Deployment Team 2 Synchronisation der Teams notwendig Synchronisation der Teams notwendig t t End2End-Tests
20. Die zunehmende Zerlegung von Anwendungen sorgt für einen Anstieg an unabhängigen Komponenten in der Anwendungslandschaft. Komponenten werden einfacher Kommunikation wird wichtiger Die Bedeutung von Integrations-Tests steigt
21. Die zunehmende Zerlegung von Anwendungen sorgt für einen Anstieg an unabhängigen Komponenten in der Anwendungslandschaft. Funktions-Tests/ Modul-Tests Integrations-Tests E2E-Tests Die Bedeutung von Integrationstests steigt. Die Testpyramide wird deutlich bauchiger.
22. 02 Tools für CDCT
23. Es existieren zwei wesentliche Frameworks für CDCT Es ist kein Glaubenskrieg. Beide Frameworks funktionieren und lassen sich miteinander integrieren. PACT Spring Cloud Contract • Community + Sponsoren • Server zur Zentralisierung der Kontrakte • Mehrere Sprachen • Spring (Pivotal) Backing • Workflow etwas aufwändiger • Fokus auf Java
24. PACT-Begriffe 24 Ein Pact umfasst einen oder mehrere Tests. Ein Test kann einen State haben. Ein State ist der Zustand in einem Provider. Einen State kann man sich wie einen Testdatensatz vorstellen. Der State wird im Test des Consumers angenommen und ist im Provider sicherzustellen.
25. Der PACT-Broker 25 Consumer .json-File Variante 1 Manuelle Weitergabe, Ablage im Repository PACT Broker Variante 2 Automatische Ablage und Versionierung, Dokumentation der Test-Ergebnisse
26. Der PACT-Broker 26 Consumer Provider Abruf der Contracts PACT Broker Consumer Consumer Testergebnisse Der Broker erhöht die Transparenz für Consumer und Provider. Er gibt zusätzlich einen Überblick über die Abhängigkeiten in der Landschaft.
27. 03 Zwischenfazit
28. Wann ist CDCT sinnvoll und wo sind die Grenzen? CDCT ist hilfreich für: • Unterstützung in der Kommunikation & Diskussion von Schnittstellen • Grundlegende Tests von Schnittstellen (Struktur, Benennung, Typisierung, Response Codes) • Beschleunigung der Entwicklung für beide Schnittstellenpartner CDCT wird nicht helfen: • Ersatz für End2End-Tests  Fokussierung von End2End-Tests • Ersatz für den Test von Business-Logik  Unit Tests • Test auf Erfüllung nicht-funktionaler Anforderungen Adaptiert von Consumer-driven Contracts, Markus Knittig (https://entwicklertag.de/karlsruhe/2018/sites/entwicklertag.de.karlsruhe.2018/files/folien/4.%20Consumer-Driven%20Contracts.pdf)
29. Kontakt Stephan Stapel stephan.stapel@hermesworld.com Diese und weitere Präsentationen findet Ihr unter: www.speakerdeck.com/hermes Kontakt Benjamin Baum benjamin.baum@hermesworld.com