Slide 1

Slide 1 text

Consumer-driven Contract Testing Java User Group Hamburg Benjamin Baum, Hermes Germany Stephan Stapel, Hermes Germany Hamburg, 01.11.2018

Slide 2

Slide 2 text

Stephan Stapel Head of Customer Solutions Benjamin Baum Software Developer

Slide 3

Slide 3 text

Inhalt 01 Warum CDCT und was ist das eigentlich? 02 Tools für CDCT 03 Zwischen-Fazit 04 Implementierung von CDCT

Slide 4

Slide 4 text

01 Warum CDCT und was ist das eigentlich?

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

Es gibt so gut wie keine Standard-Software für unser Umfeld. • Fokus auf Eigenentwicklungen • Mittelgroße Systeme • Micro Services • Viel gleichzeitige Bewegung

Slide 7

Slide 7 text

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)

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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 …

Slide 11

Slide 11 text

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.

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

02 Tools für CDCT

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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.

Slide 27

Slide 27 text

03 Zwischenfazit

Slide 28

Slide 28 text

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)

Slide 29

Slide 29 text

Kontakt Stephan Stapel [email protected] Diese und weitere Präsentationen findet Ihr unter: www.speakerdeck.com/hermes Kontakt Benjamin Baum [email protected]

Slide 30

Slide 30 text

No content