Contract testing met Pactflow (deel 1/3) : Contract test process

Zie ook:
Contract testing met Pactflow (deel 1/3) : Contract test process
Contract testing met Pactflow (deel 2/3) : Consumer test
Contract testing met Pactflow (deel 3/3) : Provider test

Voor de communicatie tussen de microservices en tussen onze microservices en externe partijen gebruiken we contract testing om de API’s te testen.

Hoe werkt contract testing?

• Definieer vanuit de aanroepende consumer een contract met de provider:
  • Welke endpoints worden gebruikt
  • Wat is de payload en headers dat je meegeeft
  • Welke payload, http status en headers dat je terug verwacht
• Contracten voor happy-flow, bad requests en server errors
• In de unit tests van de consumer: test of deze contracten goed werken met de consumer applicatie
• In een unit test van de provider: verifieer de alle contracten (van alle consumers) met de provider applicatie

Wat willen we bereiken met consumer driver contract testing?

We willen dat:

• Het voor de consumer niet mogelijk is om een versie naar productie te brengen die incompatibel is met de provider die op productie draait
• Het voor de provider niet mogelijk is om een versie naar productie te brengen die incompatibel is met de consumers die op productie draaien
• Dat een consumer een feature branch kan maken met een nieuwe api-verandering, zonder dat de provider master build daar op faalt
• Dat de provider in een feature branch de api-verandering van een consumer kan ontwikkelen en testen

Welke tools zijn er beschikbaar voor consumer driver contract testing op de jvm?

• Spring Cloud Contract
  • Alle contracten zitten bij de provider in de git-repo
  • De provider verifieert deze contracten 
  • Consumers testen hun code via de gegenereerde mocks 

• Pact.io
  • Taal onafhankelijk (js,jvm,go,python,swift,scala,php,ruby,rust,c++)
  • Contracten worden vanuit de consumer gegenereerd en getest
  • Met een pact-broker kun je de contracten op een centrale server opslaan
  • Providers halen in een unit tests deze contracten op om te valideren
  • De validatie resultaten kunnen op de broker opgeslagen worden
  • De consumer kan voordat hij naar productie deployed controleren of de master build van de provider het contract gevalideerd heeft
  • Je kunt versies en tags koppelen aan de contracts om in b.v. feature branches nieuwe change requests te ontwikkelen

Voor de rest van deze blog werk ik verder met pact.io, in combinatie met pactflow (https://pactflow.io/): een commerciële versie van de pact-broker.

Consumer unit tests:

De consumer unit tests definiëren zelf het contract. Hiervandaan wordt er on-the-fly een provider mock gegenereerd. Die kan dan gebruikt worden om te kijken of de consumer goed werkt met dit contract.
In de build pipeline kun je deze contracten (pacts) versturen naar een centrale pact broker.
Bij deze contracten kun je versies (bv de git hashcode van de consumer) meegeven en tags (bijvoorbeeld de branch-naam van de consumer).

Provider unit tests:

De provider unit test start de applicatie op, download alle contracten vanuit de pactbroker en valideerd alle contracten tegen de applicatie.
In de build pipeline kunnen de validatie resultaten terug naar de broker verstuurd worden. Ook hier kun je versies (de git hashcode van de consumer) en tags (de branch-naam van de provider) meesturen met de validatie.

De matrix:

Met behulp van de versies en tags kan de pact-broker een matrix maken waarin staat welke versie van de consumer is geverifieerd door welke versie van de provider.

De flow van een nieuw contract van een consumer:

Hieronder is te zien hoe een consumer een nieuw contract kan maken met een provider:

---

---

---

De provider unit test:

Summary:

Het proces voor het maken van een nieuw contract van een consumer met een provider werkt alsvolgt:

• Een consumer maakt een nieuwe branch aan
• De consumer maakt een unit test met daarin een nieuw contract voor een provider
• In de buildstraat wordt dat contract getagged met de branchnaam en geupload naar pactflow
• Pactflow ziet dat er een nieuw contract is, en start de master build van de provider
• De master build van de provider verifieerd alle contracten en upload het resultaat terug naar pactflow (hierbij zal de provider build alleen falen als hij een contract met de tag “master“ niet kan verifieren, als hij een contract met een andere tag niet kan valideren, dan gaat de build wel door, maar hij rapporteerd dan het contract niet gevalideerd is).
• Als het contract direct gevalideerd is, dan kan de consumer deze code mergen naar master. De stap “Can I deploy to prd?“ in de consumer build is groen als het contract gevalideerd is.
• Als het contract niet gevalideerd is, dan kan de provider een branch maken met dezelfde naam als de consumer branch. In deze branch zal hij ook op het nieuwe contract gaan testen (en er op falen als hij niet gevalideerd is). Nadat deze gefixed is kan dit gemerged worden naar master en kan de consumer ook verder mergen naar master.