Introduktion till kontraktstestning med exempel

introduction contract testing with examples

Denna handledning för testning av paktskontrakt förklarar vad som är konsumentdrivet kontraktstest, hur fungerar det och varför ska du använda det i din teststrategi:

Vad är kontraktstestning?

Konsumentdriven kontraktstestning är en form av API-testning som verkligen möjliggör skift åt vänster. Kontraktsverktyget vi använder är Pact.io , och vi kommer att lära oss mer om det senare i denna handledningsserie.

Kontrakttestning är en metod för att verifiera integrationen mellan två applikationer oberoende för att testa vad som har skickats och se om det som returneras överensstämmer med ”kontraktet”.

Kontrakttester passar fint in i en mikrotjänstarkitektur som fungerar i en smidig miljö. Exempel kommer därför att baseras på den erfarenhet vi har fått när vi arbetar i denna miljö.

Vad du kommer att lära dig:

• Lista över handledning i denna kontraktstestserie
• Konsumentdriven kontraktstestning
  • Hur fungerar det
  • Roller och ansvar
• Contract Testing Vs Integration Testing
  • Några fördelar (om du inte redan har sålt)
  • Vanliga frågor
• Fortsatt integration
• Slutsats
  • Rekommenderad läsning

Lista över handledning i denna kontraktstestserie

Handledning nr 1: Introduktion till kontraktstestning med exempel (Denna handledning)
Handledning nr 2: Hur man skriver ett konsumentavtalstest i JavaScript
Handledning nr 3: Hur man publicerar paketavtal till paketmäklare
Handledning nr 4: Verifiera paketavtal och kontinuerlig distribution med pakten CLI

Konsumentdriven kontraktstestning

Utgångspunkten är din API-dokumentation som utgör kontraktet för dina tester, vid den här punkten tar utvecklingsgrupperna API-dokumentet och utvecklas mot wikidokumentet (eller vilket format det finns i din organisation, till exempel Word Document).

Till exempel, en webbapplikation där front-end utvecklas av Team Krypton och API utvecklas av Team Thoron. Projektet inleds med ett startmöte där kraven presenteras och överenskommits mellan lagen.

Varje lag tar kraven och börjar skapa eftersläpningen genom att förfina berättelser. Utvecklingen startar i båda lagen efter användarberättelserna, integrationstestning lämnas för senare sprints. Eftersom Team Krypton hittar ytterligare krav, relaterade till felscenarier, uppdateras API-dokumentationen i enlighet med detta.

Testfall läggs till av Team Thoron relaterade till de uppdaterade scenarierna baserat på dokumentationen.

Redan kan vi se ett par brister med denna process, och jag har lagt till ett par till för lycka till:

1. Ändringar av API-dokument kanske inte kommuniceras effektivt.
2. Front-end-teamet slår ut back-end-tjänsten och vice versa.
3. Back-end-teamet skapar integrationstestfall baserat på dokumentation.
4. Integrationsmiljön är första gången när full integration testas.
5. Olika API-versioner på integrationsmiljö kontra produktion.

Konsumentdriven kontraktstestning har två sidor, dvs. konsumenten och leverantören. Det är här traditionellt tänkande om testning i mikrotjänster vänds runt.

De Konsument är kurator för scenarierna, inklusive begäran och förväntat svar. Detta gör att du kan följa Sängens lag vilket dikterar att du ska vara flexibel i vad ditt API kan acceptera men konservativt i vad som skickas. Med hänvisning till brister nr. 1, 3 och 4 drivs dokumentationsändringarna av konsumenten.

Till exempel, under de omständigheter där Team Thoron ändrar ett strängfält för att inte acceptera nollvärden skulle konsumenttesterna inte återspegla förändringen och skulle därför misslyckas. Eller åtminstone tills ändringarna hade gjorts på Team Krypton.

(bild källa )

De Leverantör verifierar de scenarier som konsumenten tillhandahåller mot deras “dev” -miljö. Detta gör att dina mikrotjänster kan tillämpas Parallell förändring som säger att du bör utöka API-funktionaliteten, följt av att migrera till en ny version. Med hänvisning till fel nr. 2, kan stubbarna som vanligtvis skapas av backend-team för sina egna testkrav nu baseras på konsumentscenarierna med Paktstubbserver .

Det bindande elementet för de två sidorna är 'kontraktet' som måste delas mellan lagen. Pakten utgör en plattform för att möjliggöra delning av kontrakt som kallas Paktmäklare (tillgänglig som en hanterad tjänst med Pactflow.io ).

De Mäklare lagrar produktionen av konsumentscenarierna. Kontraktet lagras sedan i mäklaren vid sidan av API-versionen. Detta möjliggör testning mot flera versioner av API, så kompatibilitet kan bekräftas före utgåvan, vilket markeras i fel nr 5.

En extra fördel för Paktmäklaren i de äldre plattformarna är konsumenternas synlighet. Inte alla konsumenter har varit kända för API-författarna, särskilt det är inte hur det konsumeras.

Specifikt hänvisar till en förekomst där två API-versioner stöds, det fanns ett dataproblem i version 1 (V1) där API orsakade smutsiga data i databasen.

Förändringen implementerades i V1 i API: et och drevs till produktion, men konsumenten förlitade sig på det format som orsakade dataproblemet och därigenom bröt deras integration med API.

Hur fungerar det

Exemplet ovan visar autentiseringsflödet, webbtjänsten kräver att användarna autentiserar för att komma åt känslig data. Webbtjänsten skickar en begäran till API: et om att generera en token med ett användarnamn och lösenord. API: et returnerar en bärartoken som läggs till i dataförfrågan som ett autentiseringshuvud.

Konsumenttestet konstruerar en POST-begäran om en token genom att skicka kroppen med användarnamn och lösenord.

En mock-server spunnas upp under testet som validerar den begäran du konstruerar, tillsammans med det förväntade svaret som i detta exempel inkluderar värdet för token.

Utdata från konsumenttestet genererar en paktavtalsfil. Detta kommer att lagras i paketmäklaren som version 1.

Leverantören hämtar sedan version 1 från paketmäklaren och spelar upp denna begäran mot sin lokala miljö genom att verifiera att begäran och svaret matchar konsumentkraven.

Roller och ansvar

Kvalitetssäkring (QA) / testare: Skapa kontrakt med Pact.io och arbeta med BA för att generera testscenarierna.

Utvecklare: Parar ihop med QA: erna för att skapa testerna och hjälpa till att sätta in API: et för implementering i kontinuerlig integration (CI).

Affärsanalytiker (BA): Generera scenarierna och arbeta med arkitekten för att verifiera berörda parter.

Lösningsarkitekt (Finns kanske inte i din organisation): Åtgärda API-ändringarna och samordna med BA om implementering, kommunicera också ändringar till konsumenterna (med Pact Broker för att förstå vem det kan beröra).

Släpphantering: (Ja, jag vet att det är gammaldags, men fortfarande finns i min värld): Fyllt med förtroende för att förändringar kommer att släppas framgångsrikt på grund av kontraktstestning.

Hela laget: Verifiera resultaten för att avgöra om utsläppen kan drivas till produktion med Pact CLI-verktyget, Kan jag distribuera .

Contract Testing Vs Integration Testing

Integrationstestning måste finnas för att kunna valideras om systemet fungerar innan marknadsföring till produktionsmiljön, men scenarierna kan minskas avsevärt.

Effekten av detta kan vara:

• Snabbare feedback innan du släpper till integrationsmiljön.
• Mindre beroende av stabiliteten i integrationsmiljön.
• Färre miljöer som stöder flera API-versioner.
• Minskade instabila miljöinstanser på grund av integrationsproblem.

För det första ersätter inte kontrakttestning integrationstester. Men det kan förmodligen ersätta några av dina befintliga integrationstestscenarier, flytta åt vänster och ger snabbare feedback till din livscykel för programvaruutveckling.

I integrationstest kommer du att verifiera det sammanhang som API: n lever i, såsom miljöarkitektur, distributionsprocess etc.

Därför vill du köra de centrala testscenarierna som bekräftar konfigurationen, till exempel, slutpunkten för hälsokontrollen för api-versionen. Bevisar också om implementeringen lyckades genom att returnera ett 200-svar.

Vid kontraktstestning testar du specifikationerna för API: t, som inkluderar kantfall relaterade till API-strukturen, innehållet (t.ex. fältvärden, nycklar finns) och felsvar. Till exempel, hanterar API-värdet nollvärden eller tas de bort från API-svaret (ett annat riktigt exempel).

Några fördelar (om du inte redan har sålt)

Nedan listas några av fördelarna att dra nytta av när man säljer kontraktstest till den bredare verksamheten:

• Snabbare distribution av programvara
• En enda sanningskälla
• Synlighet för alla konsumenter
• Enkel testning mot olika API-versioner.

Vanliga frågor

Några vanliga frågor när man försöker övertala människor att anta kontraktstestning inkluderar:

F # 1) Vi har redan 100% testtäckning så att vi inte behöver det.

Svar: Det är väl omöjligt, men kontraktstestning har många andra fördelar än bara testtäckning.

F # 2) Det är lösningsarkitektens ansvar att kommunicera API-ändringar.

hur man öppnar datfiler på windows

Svar: Kvalitet är hela teamets ansvar.

F # 3) Varför skapar vi testscenarier för API-teamet?

Svar: API-teamet vet inte hur webbtjänsten fungerar, så varför ska det vara ansvaret.

Fråga # 4) Våra test från slut till slut täcker hela flödet från början till slut, inklusive andra integrationspunkter.

Svar: Exakt varför vi delar upp testerna för att testa en sak och det är inte ditt ansvar att testa end-to-end-flödet i ett system som du inte vet hur det fungerar.

F # 5) I vilket lagets förvar finns testerna?

Svar: Både. Konsumenten i sitt förvar och leverantören i sitt. Sedan i den centrala punkten lever kontraktet utanför någon av dem.

Argument

Det här är argumenten som vi har svårt att argumentera mot när det gäller övergång till kontrakt för att testa:

• Swagger-dokumentation redan på plats som kan användas för att generera integrationstester.
• Team äger både front-end och back-end-tjänster med en effektiv mekanism för API-ändringar.

Fortsatt integration

Hur passar detta in i din kontinuerliga integrationstestsvit? Den önskvärda platsen för kontraktstestning att leva är med dina enhetstester.

Konsumenttester snurrar upp en mock-server som inte kräver några externa beroenden utanför testet.

Provider-test kräver en API-instans, därför kan det lokala API: et slås in med en i minnet testserver . Men om det inte är lätt att slå in ditt API lokalt, är en lösning som vi tidigare använt där vi spunnit upp en miljö och distribuerar koden till den här miljön som en del av de automatiska kontrollerna för pull-begäran.

(bild källa )

Slutsats

I den här handledningen lärde vi oss vad kontrakttester betyder och hur det ser ut i en mikroserviceinfrastruktur och såg hur det ser ut i ett verkligt exempel.

Lärdomar om hur testning av kontrakt kan hjälpa dig att flytta din integrationstest till vänster. Dessutom såg vi hur det kan minska kostnaderna för din organisation genom att minska feedbackstiderna relaterade till integrationsfrågor.

Kontrakttestning är inte bara ett verktyg för teknisk testning, det tvingar samarbetet mellan utvecklingsteam genom att kommunicera förändringar och uppmuntra testning som en enhet. Sammantaget bör detta vara en förutsättning för alla som vill flytta till kontinuerlig distribution.

NÄSTA självstudie

Rekommenderad läsning

• Hur man skriver ett konsumentavtalstest i JavaScript
• Verifiera paketavtal och kontinuerlig distribution med pakten CLI
• Hur man publicerar paketavtal till paketmäklare
• Kontinuerlig integrationsprocess: Hur man förbättrar programvarukvalitet och minskar risker
• Skillnaderna mellan enhetstestning, integrationstestning och funktionstestning
• Vad är Integration Testing (Tutorial med Integration Testing Exempel)
• Topp 10 Integrationstestverktyg för att skriva integrationstester
• Kontinuerlig distribution i DevOps