Introduktion til kontraktprøvning med eksempler

introduction contract testing with examples

Denne vejledning om test af pagtkontrakter forklarer, hvad der er forbrugerdrevet kontrakttest, hvordan fungerer det, og hvorfor skal du bruge det i din teststrategi:

Hvad er kontraktprøvning?

Forbrugerdreven kontraktprøvning er en form for API-test, der virkelig muliggør skift til venstre. Det kontraktværktøj, vi bruger, er Pact.io , og vi lærer om det senere i denne serie af tutorials.

Kontrakttestning er en metode til at verificere integrationen mellem to applikationer uafhængigt for at teste, hvad der er bestået, og se om det, der returneres, matcher 'kontrakten'.

Kontrakttests passer fint ind i en mikroservicearkitektur, der fungerer i en smidig indstilling. Eksempler vil derfor være baseret på den erfaring, vi har fået, mens vi arbejder i dette miljø.

Hvad du vil lære:

• Liste over vejledninger i denne kontraktprøvningsserie
• Forbrugerdrevet kontraktprøvning
  • Hvordan virker det
  • Roller og ansvar
• Kontrakttestning mod integrationstestning
  • Nogle fordele (hvis du ikke allerede er solgt)
  • Ofte stillede spørgsmål
• Kontinuerlig integration
• Konklusion
  • Anbefalet læsning

Liste over vejledninger i denne kontraktprøvningsserie

Tutorial # 1: Introduktion til kontraktprøvning med eksempler (Denne vejledning)
Tutorial # 2: Sådan skriver du en forbrugerpagtest i JavaScript
Tutorial # 3: Sådan udgives pagtkontrakt til pagtmægler
Tutorial # 4: Kontroller pagtkontrakt og kontinuerlig implementering med pagt CLI

Forbrugerdrevet kontraktprøvning

Udgangspunktet er din API-dokumentation, der udgør kontrakten for dine tests, på dette tidspunkt tager udviklingsholdene normalt API-dokumentet og udvikler sig mod wiki-dokumentet (eller hvilket format det ligger i din organisation, såsom Word Document).

For eksempel, en webapplikation, hvor front-end udvikles af Team Krypton og API udvikles af Team Thoron. Projektet starter med et kick-off møde, hvor kravene præsenteres og aftalt mellem holdene.

Hvert hold tager kravene og begynder at oprette efterslæbet ved at forfine historier. Udviklingen starter i begge hold efter brugerhistorierne, integrationstest er tilbage til senere sprints. Da Team Krypton finder yderligere krav, der vedrører fejlscenarier, opdateres API-dokumentationen i overensstemmelse hermed.

Testcases tilføjes af Team Thoron relateret til de opdaterede scenarier baseret på dokumentationen.

Allerede kan vi se et par fejl ved denne proces, og jeg har tilføjet et par mere til held og lykke:

1. API-dokumentændringer kommunikeres muligvis ikke effektivt.
2. Front-end-teamet stikker back-end-service ud og omvendt.
3. Back-end team opretter integrationstestsager baseret på dokumentation.
4. Integrationsmiljø er første gang, når fuld integration testes.
5. Forskellig API-version om integrationsmiljø vs produktion.

Forbrugerdreven kontraktprøvning har to sider, dvs. forbrugeren og udbyderen. Det er her, traditionel tænkning om test i mikrotjenester vendes rundt.

Det Forbruger er kurator for scenarierne, herunder anmodningen og det forventede svar. Dette giver dig mulighed for at følge Sengens lov hvilket dikterer, at du skal være fleksibel i, hvad din API kan acceptere, men konservativ i, hvad der sendes. Henvisning til fejl nr. 1, 3 og 4 er dokumentationsændringerne drevet af forbrugeren.

For eksempel, under den omstændighed, hvor Team Thoron ændrer et strengfelt for ikke at acceptere nulværdier, ville forbrugertestene ikke afspejle ændringen og derfor mislykkes. Eller i det mindste indtil ændringerne var foretaget på Team Krypton.

(billede kilde )

Det Udbyder verificerer de scenarier, som forbrugeren giver mod deres “dev” -miljø. Dette giver dine mikrotjenester mulighed for at håndhæve Parallel ændring der siger, at du skal udvide API-funktionaliteten, efterfulgt af at migrere til en ny version. Henviser tilbage til fejl nr. 2, kan de stubbe, der normalt oprettes af backend-holdene til deres egne testkrav, nu være baseret på forbrugsscenarierne ved hjælp af Paktstubserver .

Det bindende element for de to sider er 'kontrakten', som skal deles mellem holdene. Pagten er en platform, der muliggør deling af kontrakter kaldet Pagtmægler (tilgængelig som en administreret tjeneste med Pactflow.io ).

Det Mægler gemmer output fra forbrugsscenarier. Kontrakten gemmes derefter i mægleren ved siden af ​​API-versionen. Dette muliggør testning mod flere versioner af API'en, og kompatibilitet kan således bekræftes inden frigivelse, som fremhævet i fejl nr. 5.

En yderligere fordel for pagtmægleren på de ældre platforme er forbrugernes synlighed. Ikke alle forbrugere har været kendt af API-forfatterne, især det er ikke, hvordan det forbruges.

Specifikt med henvisning til en forekomst, hvor to API-versioner blev understøttet, var der et dataproblem i version 1 (V1), hvorved API'en forårsagede beskidte data i databasen.

Ændringen blev implementeret i V1 i API'en og skubbet til produktion, men forbrugeren stolede på det format, der forårsagede dataproblemet, hvorved deres integration med API blev brudt.

Hvordan virker det

Eksemplet ovenfor viser godkendelsesflowet, webservicen kræver, at brugerne godkender for at få adgang til følsomme data. Webtjenesten sender en anmodning til API'en om at generere et token ved hjælp af et brugernavn og en adgangskode. API'en returnerer et bærertoken, der føjes til dataanmodningen som en godkendelsesoverskrift.

Forbrugerprøven konstruerer en POST-anmodning om et token ved at sende kroppen med brugernavn og adgangskode.

En mock-server spindes op under testen, der validerer den anmodning, du konstruerer sammen med det forventede svar, som i dette eksempel inkluderer værdien for tokenet.

Outputtet fra forbrugertesten genererer en pagtkontraktsfil. Dette gemmes i pagtmægleren som version 1.

Udbyderen trækker derefter version 1 fra pagtmægleren og afspiller denne anmodning mod deres lokale miljø ved at kontrollere anmodningen og svaret i overensstemmelse med forbrugernes krav.

Roller og ansvar

Kvalitetssikring (QA) / Tester: Oprettelse af kontrakter ved hjælp af Pact.io og samarbejde med BA for at generere testscenarierne.

Udvikler: Parring med QA'erne om oprettelse af testene og hjælp til indpakning af API'en til implementering i Continuous Integration (CI).

Forretningsanalytiker (BA): Generering af scenarierne og samarbejde med arkitekten for at kontrollere berørte parter.

Løsningsarkitekt (Findes muligvis ikke i din organisation): Handling af API-ændringer og koordinering med BA om implementering, også kommunikation af ændringer til forbrugere (ved hjælp af Pact Broker for at forstå, hvem det kan vedrøre).

Release Management: (Ja, jeg ved, det er gammeldags, men stadig eksisterer i min verden): Fyldt med tillid til, at ændringer vil blive frigivet med succes på grund af kontraktprøvningsdækning.

Hele teamet: Kontroller resultaterne for at afgøre, om frigivelserne kan skubbes til produktion med Pact CLI-værktøjet, Kan jeg implementere .

Kontrakttestning mod integrationstestning

Integrationstest skal eksistere for at validere, hvis systemet fungerer inden forfremmelse til produktionsmiljøet, men scenarierne kan reduceres betydeligt.

Virkningen af ​​dette kan være:

• Hurtigere feedback inden frigivelse til integrationsmiljøet.
• Mindre afhængighed af stabiliteten i integrationsmiljøet.
• Færre miljøer, der understøtter flere API-versioner.
• Reducerede ustabile miljøforekomster på grund af integrationsproblemer.

For det første erstatter afprøvningstest ikke integrationstest. Men det kan sandsynligvis erstatte nogle af dine eksisterende integrationstestscenarier, skifte til venstre og giver hurtigere feedback til din softwareudviklings livscyklus.

I integrationstest vil du verificere den kontekst, som API'en lever i, såsom miljøarkitekturen, implementeringsprocessen osv.

Derfor vil du køre kernetestscenarierne, der bekræfter konfigurationen, for eksempel, endepunktet for sundhedstjek for api-versionen. Beviser også, om implementeringen var vellykket ved at returnere et 200-svar.

I afprøvningstest tester du specifikationerne for API'en, som inkluderer kanttilfælde relateret til API-strukturen, indholdet (F.eks. Feltværdier, der findes nøgler) og fejlsvar. For eksempel, håndterer API nulværdier, eller fjernes de fra API-svaret (et andet rigtigt eksempel).

tidskortapp til iPhone og Android

Nogle fordele (hvis du ikke allerede er solgt)

Nedenfor er nogle af fordelene, du kan drage fordel af, når du sælger kontraktprøvning til den bredere forretning:

• Hurtigere implementering af software
• En enkelt kilde til sandhed
• Synlighed for alle forbrugere
• Let test med forskellige API-versioner.

Ofte stillede spørgsmål

Nogle almindelige spørgsmål, når du prøver at overtale folk til at vedtage kontraktprøvning, inkluderer:

Q # 1) Vi har allerede 100% testdækning, så vi har ikke brug for det.

Svar: Nå, det er umuligt, men kontraktprøvning har mange andre fordele end bare testdækning.

Q # 2) Det er løsningsarkitektens ansvar at kommunikere API-ændringer.

Svar: Kvalitet er hele holdets ansvar.

Spørgsmål nr. 3) Hvorfor opretter vi testscenarier for API-teamet?

Svar: API-teamet ved ikke, hvordan webservicen fungerer, så hvorfor skal det være der ansvar.

Q # 4) Vores end-to-end-tests dækker hele strømmen fra start til slut, inklusive andre integrationspunkter.

Svar: Præcis hvorfor vi deler testene for at teste en ting, og det er ikke dit ansvar at teste end-to-end-flowet i et system, som du ikke ved, hvordan det fungerer.

Spørgsmål nr. 5) I hvilket holds lager findes testene?

Svar: Begge. Forbrugeren i deres lager og leverandøren i deres. Så i det centrale punkt lever kontrakten uden for en af ​​dem.

Argumenter

Dette er de argumenter, som vi har svært ved at argumentere imod, når det kommer til overgang til kontrakt for at teste:

• Swagger-dokumentation allerede på plads, som kan bruges til at generere integrationstests.
• Hold ejer både front- og back-end-tjenester med en effektiv mekanisme til API-ændringer.

Kontinuerlig integration

Hvordan passer dette ind i din kontinuerlige integrationstestsuite? Det ønskelige sted at leve kontraktkontrakter er med dine enhedstest.

Forbrugertest spinder en mock-server op, der ikke kræver nogen eksterne afhængigheder uden for testen.

Udbydertests kræver en API-forekomst, derfor kan den lokale API pakkes ind ved hjælp af en in-memory test server . Men hvis det ikke er let at pakke din API lokalt, er en løsning, som vi tidligere har brugt, hvor vi spundet et miljø op og distribuerer koden til dette miljø som en del af de automatiske kontrol af pull-anmodningen.

(billede kilde )

Konklusion

I denne vejledning lærte vi, hvad kontrakttest betyder, og hvordan det ser ud i en mikroserviceinfrastruktur og så, hvordan det ser ud i et eksempel fra den virkelige verden.

Lektioner er blevet lært om, hvordan kontraktprøvning kan hjælpe dig med at flytte din integrationstest til venstre. Derudover så vi, hvordan det kan reducere omkostningerne for din organisation ved at reducere feedbackstider relateret til integrationsproblemer.

Kontrakttestning er ikke kun et værktøj til teknisk testning, det håndhæver samarbejdet mellem udviklingshold ved at kommunikere ændringer og tilskynde til testning som en enhed. Samlet set bør dette være en forudsætning for alle, der ønsker at flytte til kontinuerlig implementering.

NÆSTE vejledning

Anbefalet læsning

• Sådan skriver du en forbrugerpagtest i JavaScript
• Kontroller pagtkontrakt og kontinuerlig implementering med pagt CLI
• Sådan udgives pagtkontrakt til pagtmægler
• Kontinuerlig integrationsproces: Sådan forbedres softwarekvaliteten og reducerer risikoen
• Forskellene mellem enhedstest, integrationstest og funktionstest
• Hvad er integrationstest (tutorial med integrationstesteksempel)
• Top 10 værktøjer til integrationstest til at skrive integrationstests
• Kontinuerlig implementering i DevOps