Inleiding tot contracttesten met voorbeelden

introduction contract testing with examples

Deze tutorial over Pact Contract Testing legt uit wat consumentgestuurde contracttesten is, hoe het werkt en waarom je het in je teststrategie zou moeten gebruiken:

Wat is contracttesten?

Consumer-Driven Contract Testing is een vorm van API-testen die shift left echt mogelijk maakt. De contracttool die we gebruiken is Pact.io , en we zullen er later in deze reeks tutorials over leren.

Contracttesten is een methode om de integratie tussen twee applicaties onafhankelijk van elkaar te verifiëren om te testen wat is geslaagd en om te zien of wat wordt geretourneerd overeenkomt met het “contract”.

Contracttests passen mooi binnen een microservice-architectuur, opererend in een agile setting. Daarom zullen voorbeelden gebaseerd zijn op de ervaring die we hebben opgedaan tijdens het werken in deze omgeving.

Wat je leert:

• Lijst met zelfstudies in deze serie contracttests
• Klantgerichte contracttesten
  • Hoe werkt het
  • Rollen en verantwoordelijkheden
• Contracttesten versus integratietesten
  • Enkele voordelen (als u nog niet bent verkocht)
  • Veel Gestelde Vragen
• Continue integratie
• Gevolgtrekking
  • Aanbevolen literatuur

Lijst met zelfstudies in deze serie contracttests

Tutorial # 1: Inleiding tot contracttesten met voorbeelden (Deze tutorial)
Tutorial # 2: Hoe een consumentenpacttest in JavaScript te schrijven
Tutorial # 3: Hoe een pactcontract naar een pactmakelaar te publiceren
Tutorial # 4: Verifieer pactcontract en continue implementatie met Pact CLI

Klantgerichte contracttesten

Het startpunt is uw API-documentatie die het contract vormt voor uw tests, op dit punt nemen de ontwikkelteams meestal het API-document en ontwikkelen ze op basis van het wiki-document (of welk formaat het ook in uw organisatie heeft, zoals Word-document).

Bijvoorbeeld, een webapplicatie waarbij de front-end wordt ontwikkeld door Team Krypton en de API wordt ontwikkeld door Team Thoron. Het project begint met een kick-off meeting waar de eisen worden gepresenteerd en afgesproken tussen de teams.

Elk team neemt de vereisten en begint de backlog te creëren door verhalen te verfijnen. De ontwikkeling start in beide teams volgens de user stories, integratietesten worden overgelaten voor latere sprints. Aangezien Team Krypton aanvullende vereisten vindt met betrekking tot foutscenario's, wordt de API-documentatie dienovereenkomstig bijgewerkt.

Testcases worden toegevoegd door Team Thoron met betrekking tot de bijgewerkte scenario's op basis van de documentatie.

We kunnen nu al een aantal tekortkomingen zien in dit proces, en ik heb er nog een paar toegevoegd voor veel geluk:

1. Wijzigingen in API-documenten worden mogelijk niet effectief gecommuniceerd.
2. Front-end-team verdringt de back-end-service en vice versa.
3. Back-endteam creëert integratietestcases op basis van documentatie.
4. Integratieomgeving is de eerste keer dat volledige integratie wordt getest.
5. Verschillende API-versies op integratieomgeving versus productie.

Consumentgestuurde contracttesten hebben twee kanten, namelijk de consument en de aanbieder. Dit is waar het traditionele denken over testen in microservices wordt omgedraaid.

De Klant is de curator van de scenario's, inclusief het verzoek en de verwachte reactie. Hierdoor kun je volgen Bed's wet wat dicteert dat u flexibel moet zijn in wat uw API kan accepteren, maar conservatief in wat wordt verzonden. Terugverwijzend naar gebreken nr. 1, 3 en 4, worden de documentatiewijzigingen aangestuurd door de consument.

Bijvoorbeeld, in het geval dat Team Thoron een stringveld wijzigt om geen nulwaarden te accepteren, zouden de consumententests de verandering niet weergeven en daarom mislukken. Of in ieder geval totdat de wijzigingen waren aangebracht in Team Krypton.

(beeld bron ​

De Aanbieder verifieert de scenario's die door de consument worden geleverd aan de hand van hun 'dev' -omgeving. Hierdoor kunnen uw microservices afdwingen Parallelle verandering waarin staat dat u de API-functionaliteit moet uitbreiden, gevolgd door migreren naar een nieuwe versie. Terugverwijzend naar fout nr. 2, kunnen de stubs die gewoonlijk door de back-endteams worden gemaakt voor hun eigen testvereisten nu worden gebaseerd op de consumentenscenario's met Pact Stub Server ​

Het bindende element van de twee partijen is het 'contract' dat tussen de teams moet worden gedeeld. Het pact biedt een platform om het delen van contracten mogelijk te maken, het Pact-makelaar (beschikbaar als managed service bij Pactflow.io ​

De Makelaar slaat de output van de consumentenscenario's op. Het contract wordt dan naast de versie van de API opgeslagen binnen de broker. Dit maakt testen met meerdere versies van de API mogelijk, waardoor compatibiliteit kan worden bevestigd vóór de release, zoals benadrukt in fout nr. 5.

Een bijkomend voordeel van de Pact Broker in de oude platforms is de zichtbaarheid van de consument. Niet alle consumenten zijn bekend bij de API-auteurs, vooral niet hoe het wordt geconsumeerd.

Specifiek verwijzend naar een gebeurtenis waarbij twee API-versies werden ondersteund, was er een gegevensprobleem in versie 1 (V1) waardoor de API vuile gegevens in de database.

De wijziging werd geïmplementeerd in V1 van de API en gepusht naar productie, maar de consument vertrouwde op het formaat dat het gegevensprobleem veroorzaakte, waardoor de integratie met de API werd verbroken.

Hoe werkt het

Het bovenstaande voorbeeld toont de authenticatiestroom, de webservice vereist dat de gebruikers authenticeren om toegang te krijgen tot gevoelige gegevens. De webservice stuurt een verzoek naar de API om een ​​token te genereren met een gebruikersnaam en wachtwoord. De API retourneert een dragertoken dat wordt toegevoegd aan het gegevensverzoek als authenticatieheader.

De Consumententest construeert een POST-verzoek voor een token door de body met gebruikersnaam en wachtwoord door te geven.

Tijdens de test wordt een nepserver geactiveerd die het verzoek dat u construeert, valideert, samen met het verwachte antwoord dat in dit voorbeeld de waarde voor het token bevat.

De output van de consumententest levert een pactcontractdossier op. Dit wordt opgeslagen in de pactbroker als versie 1.

De provider haalt vervolgens versie 1 uit de pactbroker en speelt dit verzoek opnieuw af tegen hun lokale omgeving door te verifiëren dat het verzoek en het antwoord overeenkomen met de eisen van de consument.

Rollen en verantwoordelijkheden

Kwaliteitsborging (QA) / tester: Contracten maken met Pact.io en samenwerken met de BA om de testscenario's te genereren.

Ontwikkelaar: Koppelen met de QA's bij het maken van de tests en helpen bij het verpakken van de API voor implementatie in Continuous Integration (CI).

Bedrijfsanalist (BA): Het genereren van de scenario's en het samenwerken met de architect om de betrokken partijen te verifiëren.

Oplossingsarchitect (Mogelijk niet aanwezig in uw organisatie): Het uitvoeren van de API-wijzigingen en het coördineren met de BA over de implementatie, ook het communiceren van wijzigingen aan de consumenten (gebruikmakend van de Pact Broker om te begrijpen wie het aangaat).

Releasebeheer: (Ja, ik weet dat het ouderwets is, maar het bestaat nog steeds in mijn wereld): Vol vertrouwen dat wijzigingen met succes zullen worden vrijgegeven vanwege de dekking van contracttests.

Hele team: Verifieer de resultaten om te bepalen of de releases naar productie kunnen worden gepusht met de Pact CLI-tool, Kan ik implementeren ​

Contracttesten versus integratietesten

Er moeten integratietests zijn om te valideren of het systeem werkt voordat het naar de productieomgeving wordt gepromoot, maar de scenario's kunnen aanzienlijk worden verminderd.

De impact hiervan kan zijn:

• Snellere feedback voordat deze wordt vrijgegeven aan de integratieomgeving.
• Minder afhankelijkheid van de stabiliteit van de integratieomgeving.
• Minder omgevingen die meerdere API-versies ondersteunen.
• Minder instabiele omgevingsinstanties vanwege integratieproblemen.

Ten eerste is contracttesten geen vervanging van integratietesten. Maar het kan waarschijnlijk enkele van uw bestaande integratietestscenario's vervangen, naar links verschuiven en snellere feedback geven op uw softwareontwikkelingscyclus.

Bij integratietests verifieer je de context waarin de API leeft, zoals de omgevingsarchitectuur, het implementatieproces, enz.

Daarom wilt u de kerntestscenario's uitvoeren die de configuratie zouden bevestigen, bijvoorbeeld, het statuscontrole-eindpunt voor de api-versie. Ook bewijzen of de implementatie succesvol was door een respons van 200 te retourneren.

Bij contracttesten test u de specifieke kenmerken van de API, waaronder de randgevallen met betrekking tot de API-structuur, inhoud (bijv. Veldwaarden, sleutels bestaan) en foutreacties. Bijvoorbeeld, verwerkt de API null-waarden of worden ze verwijderd uit het API-antwoord (een ander echt voorbeeld).

Enkele voordelen (als u nog niet bent verkocht)

Hieronder vindt u enkele van de voordelen waarvan u kunt profiteren bij het verkopen van contracttests aan het bredere bedrijf:

• Snellere implementatie van software
• Een enkele bron van waarheid
• Zichtbaarheid van alle consumenten
• Gemakkelijk testen tegen verschillende API-versies.

Veel Gestelde Vragen

Enkele veelgestelde vragen bij het overtuigen van mensen om contracttesten toe te passen, zijn:

V # 1) We hebben al 100% testdekking, dus we hebben het niet nodig.

hoe .jar-bestanden te openen met java

Antwoord: Dat is onmogelijk, maar contracttesten hebben veel andere voordelen dan alleen testdekking.

Vraag 2) Het is de verantwoordelijkheid van de oplossingsarchitect om API-wijzigingen door te geven.

Antwoord: Kwaliteit is de verantwoordelijkheid van het hele team.

V # 3) Waarom maken we de testscenario's voor het API-team?

Antwoord: Het API-team weet niet hoe de webservice werkt, dus waarom zou het hun verantwoordelijkheid moeten hebben?

V # 4) Onze end-to-end-tests bestrijken de hele stroom van begin tot eind, inclusief andere integratiepunten.

Antwoord: Precies waarom we de tests splitsen om één ding te testen, en het is niet uw verantwoordelijkheid om de end-to-end-stroom van een systeem te testen waarvan u niet weet hoe het werkt.

V # 5) In de opslagplaats van welk team worden de tests uitgevoerd?

Antwoord: Beide. De consument in hun repository en Provider in die van hen. Dan leeft het contract op het centrale punt buiten een van beide.

Argumenten

Dit zijn de argumenten waar we moeilijk tegen in kunnen gaan als het gaat om de overgang naar contract om te testen:

• Swagger-documentatie al aanwezig die kan worden gebruikt om integratietests te genereren.
• Teams zijn eigenaar van zowel front-end- als back-endservices met een effectief mechanisme voor API-wijzigingen.

Continue integratie

Hoe past dit in uw testsuite voor continue integratie? De gewenste plaats voor contracttesten om te wonen, is bij uw unit-tests.

Consumententests leiden tot een nepserver die geen externe afhankelijkheden vereist buiten de test.

Providertests vereisen een API-instantie, daarom kan de lokale API worden verpakt met een in-memory testserver ​Als het echter niet eenvoudig is om uw API lokaal te verpakken, is een tijdelijke oplossing die we eerder hebben gebruikt, waar we een omgeving opzetten en de code in deze omgeving implementeren als onderdeel van de automatische controles van het pull-verzoek.

(beeld bron ​

Gevolgtrekking

In deze tutorial hebben we geleerd wat contracttesten inhoudt en hoe het eruit ziet in een microservice-infrastructuur, en hoe het eruit ziet in een real-world voorbeeld.

Er zijn lessen geleerd over hoe contracttesten u kan helpen uw inburgeringstoets naar links te verschuiven. Daarnaast hebben we gezien hoe het de kosten voor uw organisatie kan verlagen door feedbacktijden met betrekking tot integratieproblemen te verkorten.

Contracttesten is niet alleen een hulpmiddel voor technisch testen, het dwingt de samenwerking van ontwikkelteams af door veranderingen te communiceren en testen aan te moedigen als één geheel. Over het algemeen zou dit een voorwaarde moeten zijn voor iedereen die naar continue implementatie wil overstappen.

VOLGENDE zelfstudie

Aanbevolen literatuur

• Hoe een consumentenpacttest in JavaScript te schrijven
• Verifieer pactcontract en continue implementatie met Pact CLI
• Hoe een pactcontract naar een pactmakelaar te publiceren
• Continu integratieproces: hoe u de softwarekwaliteit kunt verbeteren en risico's kunt verminderen
• De verschillen tussen unit-tests, integratietests en functionele tests
• Wat is integratietesten (zelfstudie met voorbeeld van integratietesten)
• Top 10 integratietesttools om integratietests te schrijven
• Continue implementatie in DevOps