Introduksjon til kontraktstesting med eksempler

introduction contract testing with examples

Denne veiledningen for test av paktkontrakter forklarer hva som er forbrukerstyrt kontraktstesting, hvordan fungerer det og hvorfor bør du bruke det i teststrategien din:

Hva er kontraktstesting?

Forbrukerstyrt kontraktstesting er en form for API-testing som virkelig muliggjør skift til venstre. Kontraktsverktøyet vi bruker er Pact.io , og vi vil lære om det senere i denne veiledningen.

Kontrakttesting er en metode for å verifisere integrering mellom to applikasjoner uavhengig for å teste hva som er blitt bestått og se om det som returneres samsvarer med 'kontrakten'.

Kontrakttester passer fint innenfor en mikroservicearkitektur, som opererer i en smidig setting. Eksempler vil derfor være basert på den erfaringen vi har fått mens vi jobber i dette miljøet.

Hva du vil lære:

• Liste over veiledninger i denne kontraktsprøveserien
• Forbrukerdrevet kontraktstesting
  • Hvordan virker det
  • Roller og ansvar
• Kontrakttesting mot integrasjonstesting
  • Noen fordeler (hvis du ikke allerede er solgt)
  • ofte stilte spørsmål
• Kontinuerlig integrering
• Konklusjon
  • Anbefalt lesing

Liste over veiledninger i denne kontraktsprøveserien

Opplæring # 1: Introduksjon til kontraktstesting med eksempler [Denne veiledningen]
Opplæring nr. 2: Hvordan skrive en forbrukerpaktest i JavaScript
Opplæring # 3: Hvordan publisere paktkontrakt til paktmegler
Opplæring # 4: Bekreft paktkontrakt og kontinuerlig distribusjon med pakt CLI

Forbrukerdrevet kontraktstesting

Utgangspunktet er API-dokumentasjonen din som danner kontrakten for testene dine, på dette punktet tar utviklingslagene vanligvis API-dokumentet og utvikler seg mot wiki-dokumentet (eller hvilket format det ligger i organisasjonen din, for eksempel Word Document).

For eksempel, en webapplikasjon der front-end utvikles av Team Krypton og API utvikles av Team Thoron. Prosjektet starter med et kick-off møte der kravene presenteres og avtales mellom lagene.

Hvert team tar kravene og begynner å lage etterslepet ved å finpusse historiene. Utviklingen starter i begge lagene etter brukerhistoriene, integrasjonstesting er igjen for senere sprints. Da Team Krypton finner flere krav, knyttet til feilscenarier, oppdateres API-dokumentasjonen tilsvarende.

Test tilfeller er lagt til av Team Thoron relatert til oppdaterte scenarier basert på dokumentasjonen.

Allerede kan vi se et par feil ved denne prosessen, og jeg har lagt til et par til for lykke til:

1. Endringer i API-dokument kan ikke kommuniseres effektivt.
2. Front-end-teamet stikker ut back-end-tjenesten og omvendt.
3. Back-end team lager integrasjonstestsaker basert på dokumentasjon.
4. Integreringsmiljø er første gang full integrering testes.
5. Ulike API-versjon på integrasjonsmiljø vs produksjon.

Forbrukerdrevet kontraktstesting har to sider, dvs. forbrukeren og leverandøren. Det er her tradisjonell tenking om testing i mikrotjenester vendes rundt.

De Forbruker er kurator for scenariene, inkludert forespørselen og forventet svar. Dette lar deg følge Sengens lov som dikterer at du skal være fleksibel i hva API-en din kan godta, men konservativ i det som sendes. Med henvisning til feil nr. 1, 3 og 4, er dokumentasjonsendringene drevet av forbrukeren.

For eksempel, i den omstendighet hvor Team Thoron endrer et strengfelt for ikke å akseptere nullverdier, vil ikke forbrukernes tester gjenspeile endringen og vil derfor mislykkes. Eller i det minste til endringene hadde blitt gjort på Team Krypton.

[bilde kilde ]

De Forsørger verifiserer scenariene som tilbys av forbrukeren mot deres “dev” -miljø. Dette gjør at mikrotjenestene dine kan håndheves Parallell endring som sier at du bør utvide API-funksjonaliteten, etterfulgt av å migrere til en ny versjon. Med henvisning til feil nr. 2, kan stubber som vanligvis opprettes av back-end-teamene for sine egne testkrav nå være basert på forbrukerscenariene ved å bruke Paktstubserver .

Det bindende elementet til de to sidene er 'kontrakten' som må deles mellom lagene. Pakten gir en plattform for å muliggjøre deling av kontrakter kalt Paktmegler (tilgjengelig som en administrert tjeneste med Pactflow.io ).

De Megler lagrer produksjonen fra forbrukerscenariene. Kontrakten lagres deretter i megleren sammen med versjonen av API. Dette muliggjør testing mot flere versjoner av API, og kompatibilitet kan dermed bekreftes før utgivelse, som fremhevet i feil nr. 5.

En ekstra fordel for Paktmegleren på de eldre plattformene er synligheten til forbrukerne. Ikke alle forbrukere har vært kjent for API-forfatterne, spesielt det er ikke slik det forbrukes.

Spesielt med henvisning til en forekomst der to API-versjoner ble støttet, var det et dataproblem i versjon 1 (V1) der APIen forårsaket skitne data i databasen.

Endringen ble implementert i V1 av API og presset til produksjon, men forbrukeren stolte på formatet som forårsaket dataproblemet, og dermed brøt integrasjonen med API.

Hvordan virker det

Eksemplet ovenfor viser autentiseringsflyten, nettjenesten krever at brukerne autentiserer for å få tilgang til sensitive data. Nettjenesten sender en forespørsel til APIen om å generere et token ved hjelp av brukernavn og passord. API returnerer et bærertoken som legges til dataforespørselen som et autentiseringshode.

Forbrukertesten konstruerer en POST-forespørsel om et token ved å sende kroppen med brukernavn og passord.

En mock-server spinnes opp under testen som validerer forespørselen du konstruerer, sammen med det forventede svaret som i dette eksemplet inkluderer verdien for tokenet.

Utdataene fra forbrukertesten genererer en paktkontraktsfil. Dette lagres i paktsmegleren som versjon 1.

Leverandøren henter deretter versjon 1 fra paktsmegleren og spiller denne forespørselen på nytt mot sitt lokale miljø, ved å verifisere forespørselen og svaret samsvarer med forbrukernes krav.

Roller og ansvar

Kvalitetssikring (QA) / Tester: Opprette kontrakter ved bruk av Pact.io og samarbeide med BA for å generere testscenariene.

Utvikler: Sammenkobling med kvalitetssikringene for å lage testene og hjelpe til med å pakke inn API for implementering i kontinuerlig integrasjon (CI).

Forretningsanalytiker (BA): Generere scenariene og samarbeide med arkitekten for å verifisere berørte parter.

Løsningsarkitekt (Kan ikke eksistere i organisasjonen din): Handle API-endringene og koordinere med BA om implementering, og kommunisere også endringer til forbrukerne (ved å bruke Paktmegleren for å forstå hvem det kan dreie seg om).

Utgivelsesadministrasjon: (Ja, jeg vet at det er gammeldags, men fortsatt eksisterer i min verden): Fylt med tillit til at endringer vil bli utgitt med suksess på grunn av kontrakttesting.

Hele laget: Bekreft resultatene for å avgjøre om utgivelsene kan skyves til produksjon med Pact CLI-verktøyet, Kan jeg distribuere .

Kontrakttesting mot integrasjonstesting

Integrasjonstesting må eksistere for å validere om systemet fungerer før markedsføring til produksjonsmiljøet, men scenariene kan reduseres betydelig.

Virkningen av dette kan være:

• Raskere tilbakemelding før du slipper til integrasjonsmiljøet.
• Mindre avhengighet av stabiliteten i integrasjonsmiljøet.
• Færre miljøer som støtter flere API-versjoner.
• Reduserte ustabile miljøforekomster på grunn av integrasjonsproblemer.

For det første erstatter ikke kontrakttesting integrasjonstesting. Men det kan sannsynligvis erstatte noen av dine eksisterende integrasjonstest-scenarier, skifte til venstre og gi raskere tilbakemeldinger til programvaren din.

I integrasjonstesting vil du verifisere sammenhengen API-en lever i, for eksempel miljøarkitekturen, distribusjonsprosessen osv.

Derfor vil du kjøre de viktigste testscenariene som vil bekrefte konfigurasjonen, for eksempel, endepunktet for helsekontrollen for api-versjonen. Beviser også om distribusjonen var vellykket ved å returnere 200 svar.

I kontrakttesting tester du detaljene til API, som inkluderer kanttilfeller relatert til API-struktur, innhold (F.eks. Feltverdier, nøkler eksisterer) og feilrespons. For eksempel, håndterer API nullverdier eller blir de fjernet fra API-svaret (et annet reelt eksempel).

Noen fordeler (hvis du ikke allerede er solgt)

Nedenfor er noen av fordelene du kan dra nytte av når du selger kontraktstesting til bredere virksomhet:

• Raskere distribusjon av programvare
• En eneste kilde til sannhet
• Synlighet for alle forbrukere
• Enkel testing mot forskjellige API-versjoner.

ofte stilte spørsmål

Noen vanlige spørsmål når du prøver å overtale folk til å vedta kontraktstesting inkluderer:

hvordan du legger til et element i en matrise i java

Q # 1) Vi har allerede 100% testdekning, så vi trenger ikke den.

Svar: Det er vel umulig, men kontrakttesting har mange andre fordeler enn bare testdekning.

Q # 2) Det er løsningsarkitektens ansvar å kommunisere API-endringer.

Svar: Kvalitet er hele teamets ansvar.

Spørsmål 3) Hvorfor lager vi testscenarier for API-teamet?

Svar: API-teamet vet ikke hvordan nettjenesten fungerer, så hvorfor skal den være ansvarlig.

Q # 4) Våre end-to-end tester dekker hele flyten fra start til slutt, inkludert andre integrasjonspunkter.

Svar: Nøyaktig hvorfor vi deler testene for å teste en ting, og det er ikke ditt ansvar å teste end-to-end-strømmen til et system som du ikke vet hvordan det fungerer.

Spørsmål nr. 5) I hvilket lagets lagringsplass bor testene?

Svar: Både. Forbrukeren i deres depot og leverandøren i sitt. Så i det sentrale punktet lever kontrakten utenfor en av dem.

Argumenter

Dette er argumentene som vi synes det er vanskelig å argumentere mot når det gjelder overgang til kontrakt for å teste:

• Swagger dokumentasjon allerede på plass som kan brukes til å generere integrasjonstester.
• Lag eier både front- og back-end-tjenester med en effektiv mekanisme for API-endringer.

Kontinuerlig integrering

Hvordan passer dette inn i testpakken for kontinuerlig integrasjon? Det ønskelige stedet for kontraktstesting å leve er med enhetstestene dine.

Forbrukertester spinner opp en mock-server som ikke krever eksterne avhengigheter utenfor testen.

Tilbydertester krever en API-forekomst, og derfor kan den lokale APIen pakkes inn ved hjelp av en i minnetestserver . Imidlertid, hvis det ikke er lett å pakke inn API-en din lokalt, er en løsning som vi tidligere har brukt, der vi spunnet opp et miljø og distribuerer koden til dette miljøet som en del av de automatiske kontrollene for pull-forespørselen.

[bilde kilde ]

Konklusjon

I denne veiledningen lærte vi hva kontrakttesting betyr og hvordan det ser ut i en mikroserviceinfrastruktur, og så hvordan det ser ut i et eksempel fra den virkelige verden.

Leksjoner har blitt lært om hvordan kontrakttesting kan hjelpe deg med å flytte integrasjonstesten til venstre. I tillegg så vi hvordan det kan redusere kostnadene for organisasjonen din ved å redusere tilbakemeldingstider knyttet til integrasjonsproblemer.

Kontrakttesting er ikke bare et verktøy for teknisk testing, det håndhever samarbeidet mellom utviklingsteam ved å kommunisere endringer og oppmuntre til testing som en enhet. Samlet sett bør dette være en forutsetning for alle som ønsker å flytte til kontinuerlig distribusjon.

NESTE veiledning

Anbefalt lesing

• Hvordan skrive en forbrukerpaktest i JavaScript
• Bekreft paktkontrakt og kontinuerlig distribusjon med pakt CLI
• Hvordan publisere paktkontrakt til paktmegler
• Kontinuerlig integrasjonsprosess: Hvordan forbedre programvarekvaliteten og redusere risikoen
• Forskjellene mellom enhetstesting, integrasjonstesting og funksjonstesting
• Hva er integrasjonstesting (opplæring med eksempel på integrasjonstesting)
• Topp 10 integrasjonstestverktøy for å skrive integrasjonstester
• Kontinuerlig distribusjon i DevOps