Meni

Uvod v pogodbeno testiranje s primeri

introduction contract testing with examples

Preizkusite Naš Instrument Za Odpravo Težav

java 8 novih funkcij s primeri

Ta vadnica o pogodbenem preizkušanju pojasnjuje, kaj je potrošniško preizkušanje pogodb, kako deluje in zakaj bi ga morali uporabljati v svoji strategiji testiranja:

Kaj je pogodbeno testiranje?

Potrošniško pogodbeno testiranje je oblika testiranja API, ki resnično omogoča premik levo. Pogodbeno orodje, ki ga uporabljamo, je Pact.io , in o tem bomo izvedeli kasneje v tej seriji vadnic.

Testiranje pogodb je metoda za neodvisno preverjanje integracije med dvema aplikacijama, da se preizkusi, kaj je bilo preneseno, in ugotovi, ali se vrnjeno ujema z 'pogodbo'.

Naročniški testi se lepo prilegajo arhitekturi mikroservisov in delujejo v gibčni nastavitvi. Zato bodo primeri temeljili na izkušnjah, ki smo jih pridobili med delom v tem okolju.

Testiranje po pogodbi

Kaj se boste naučili:

Seznam vadnic v tej pogodbeni preizkusni seriji

Vadnica št. 1: Uvod v pogodbeno preskušanje s primeri (Ta vadnica)
Vadnica # 2: Kako napisati test potrošniškega pakta v JavaScript
Vadnica št. 3: Kako objaviti pogodbo o pogodbi s posrednikom
Vadnica # 4: Preverite pogodbo o pogodbi in neprekinjeno uvajanje s paktom CLI

Potrošniško pogodbeno preskušanje

Izhodišče je vaša dokumentacija API-ja, ki tvori pogodbo za vaše teste. Na tej točki običajno razvojne skupine vzamejo dokument API-ja in razvijejo v skladu z wiki-dokumentom (ali v kateri koli obliki, ki je v vaši organizaciji, na primer Wordov dokument).

Na primer spletna aplikacija, kjer front-end razvija Team Krypton, API pa Team Thoron. Projekt se začne z začetnim sestankom, kjer se zahteve predstavijo in dogovorijo med skupinama.

Vsaka ekipa sprejme zahteve in začne z izboljševanjem zgodb ustvarjati zaostanek. Razvoj se začne v obeh ekipah po zgodbah uporabnikov, integracijsko testiranje pa je prepuščeno poznejšim sprintom. Ker ekipa Krypton najde dodatne zahteve glede scenarijev napak, se dokumentacija API ustrezno posodobi.

Team Thoron doda testne primere, povezane s posodobljenimi scenariji na podlagi dokumentacije.

Že pri tem postopku vidimo nekaj napak, za srečo pa sem dodal še nekaj:

  1. Spremembe dokumentov API morda ne bodo učinkovite.
  2. Front-end ekipa izniči back-end storitve in obratno.
  3. Skupina zalednih uporabnikov na podlagi dokumentacije ustvari testne primere integracije.
  4. Integracijsko okolje je prvič, da se preizkusi popolna integracija.
  5. Različna različica API-ja za integracijsko okolje in produkcijo.

Potrošniško pogodbeno testiranje ima dve plati, tj.potrošnika in ponudnika. Tu se preusmeri tradicionalno razmišljanje o testiranju v mikro storitvah.

The Potrošnik je kustos scenarijev, vključno z zahtevo in pričakovanim odzivom. To vam omogoča sledenje Bedov zakon kar narekuje, da bi morali biti prilagodljivi pri sprejemanju vašega API-ja, vendar konzervativni pri pošiljanju. Sklicevanje nazaj na pomanjkljivosti št. 1, 3 in 4, spremembe dokumentacije vodi potrošnik.

Na primer v okoliščinah, ko Team Thoron spremeni polje niza, da ne sprejme ničelnih vrednosti, potrošniški testi ne bi odražali spremembe in zato ne bi uspeli. Ali vsaj do sprememb ekipe Team Krypton.

Določite pričakovanja potrošnikov

(slika vir )

The Ponudnik preveri scenarije, ki jih ponuja potrošnik, glede na njegovo 'razvojno' okolje. To omogoča, da vaše mikro storitve uveljavijo Vzporedna sprememba ki navaja, da morate razširiti funkcionalnost API-ja, čemur sledi selitev na novo različico. Sklicevanje nazaj na napako št. 2, škrbine, ki jih običajno ustvarijo zaledne ekipe za lastne potrebe testiranja, lahko zdaj temeljijo na potrošniških scenarijih z uporabo Pact Stub Server .

Preverite pričakovanja ponudnika

Obvezujoč element obeh strani je 'pogodba', ki si jo morata moštvi deliti. Pakt zagotavlja platformo, ki omogoča skupno rabo pogodb, imenovanih Pakt Broker (na voljo kot upravljana storitev z Pactflow.io ).

The Posrednik shranjuje rezultate potrošniških scenarijev. Nato se pogodba shrani pri posredniku skupaj z različico API-ja. To omogoča testiranje na več različicah API-ja, zato je združljivost mogoče potrditi pred izdajo, kot je poudarjeno v napaki št.

pact_network_diagram
Pact Broker - vizualna predstavitev

Dodatna prednost Pact Broker na starih platformah je prepoznavnost potrošnikov. Avtorjem API-jev niso znani vsi potrošniki, še posebej ne glede na to, kako se porabijo.

Natančneje glede na pojav, ko sta bili podprti dve različici API, je prišlo do težave s podatki v različici 1 (V1), zaradi katere je API povzročal umazani podatki v zbirki podatkov.

Sprememba je bila izvedena v V1 API-ja in potisnjena v produkcijo, vendar se je potrošnik zanesel na obliko, ki je povzročala težavo s podatki, in s tem prekinil njihovo integracijo z API-jem.

Kako deluje

Tok overjanja

Zgornji primer prikazuje tok preverjanja pristnosti, spletna storitev od uporabnikov zahteva, da se overjajo, da lahko dostopajo do občutljivih podatkov. Spletna storitev API-ju pošlje zahtevo za generiranje žetona z uporabniškim imenom in geslom. API vrne žeton nosilca, ki je zahtevi za podatke dodan kot glava za preverjanje pristnosti.

Potrošniški test ustvari zahtevo POST za žeton tako, da preda telo z uporabniškim imenom in geslom.

Zahteva POST

Med preskusom se zavrti lažni strežnik, ki potrdi zahtevo, ki jo sestavite, skupaj s pričakovanim odzivom, ki v tem primeru vključuje vrednost žetona.

lažni strežnik

Rezultat preizkusa potrošnikov ustvari pogodbeno datoteko pakta. Ta bo shranjena v posredniku pakta kot različica 1.

Nato ponudnik povleče različico 1 od posrednika pakta in to zahtevo predvaja v svojem lokalnem okolju, tako da preveri, ali se zahteva in odziv ujemata z zahtevami potrošnikov.

paktni posrednik

Vloge in odgovornosti

Vloge in odgovornosti

Zagotavljanje kakovosti (QA) / Tester: Ustvarjanje pogodb z uporabo Pact.io in sodelovanje z BA za ustvarjanje testnih scenarijev.

Razvijalec: Seznanjanje z vprašanji kakovosti pri ustvarjanju testov in pomoč pri zavijanju API-ja za izvajanje v neprekinjeno integracijo (CI).

youtube v mp3 pretvornik brezplačen prenos

Poslovni analitik (BA): Ustvarjanje scenarijev in sodelovanje z arhitektom za preverjanje prizadetih strani.

Arhitekt rešitve (Morda ne obstaja v vaši organizaciji): Ukrepanje v zvezi s spremembami API-ja in usklajevanje z BA o izvedbi, prav tako sporočanje sprememb potrošnikom (z uporabo Pact Brokerja, da bi razumeli, koga to lahko zadeva).

Upravljanje izdaje: (Da, vem, da je staromoden, vendar še vedno obstaja v mojem svetu): Izpolnjen z zaupanjem, da bodo spremembe zaradi izdaje pogodbenega testiranja uspešno objavljene.

Celotna ekipa: Preverite rezultate, da ugotovite, ali lahko izdaje potisnete v produkcijo z orodjem Pact CLI, Ali lahko razmestim .

Pogodbeno preskušanje vs integracijsko preskušanje

Obstajati mora integracijsko testiranje, da se preveri, če sistem deluje pred promocijo v proizvodno okolje, vendar je mogoče scenarije znatno zmanjšati.

Vpliv tega bi lahko bil:

  • Hitrejše povratne informacije pred sprostitvijo v integracijsko okolje.
  • Manj zanašanja na stabilnost integracijskega okolja.
  • Manj okolij, ki podpirajo več različic API.
  • Manj primerov nestabilnega okolja zaradi težav z integracijo.
IntegracijaPogodba
Jasno je, da natančno odpovemoVeliko plastiZelo enostavno
Konfiguracija API-jaDaNe
Pregledi uvajanjaDaNe
Različenje API-jevDaDa
Lokalno odpravite napakeNeDa
Okoljska vprašanjaDaNe
Čas povratne informacijePočasiHitro

Prvič, pogodbeno testiranje ne nadomešča integracijskega testiranja. Verjetno pa lahko nadomesti nekatere obstoječe scenarije integracijskega preskusa, premakne se v levo in omogoči hitrejše povratne informacije o življenjskem ciklu razvoja programske opreme.

Pri integracijskem testiranju boste preverjali kontekst, v katerem živi API, na primer arhitektura okolja, postopek uvajanja itd.

Zato želite zagnati osnovne testne scenarije, ki bi potrdili konfiguracijo, na primer, končna točka zdravstvenega pregleda za različico api. Tudi dokazovanje, ali je bila razmestitev uspešna, je vrnil odgovor 200.

Pri preizkušanju pogodb preizkušate posebnosti API-ja, ki vključuje robne primere, povezane s strukturo API-ja, vsebino (npr. Vrednosti polj, ključi obstajajo) in odzivi na napake. Na primer ali API obravnava ničelne vrednosti ali so odstranjene iz odziva API (še en resničen primer).

Nekaj ​​ugodnosti (če še niste prodani)

Spodaj so navedene nekatere prednosti, ki jih je treba izkoristiti pri prodaji pogodbenega testiranja širšemu podjetju:

  • Hitrejša uporaba programske opreme
  • En sam vir resnice
  • Vidnost vseh potrošnikov
  • Enostavnost testiranja na različnih različicah API.

Pogosto zastavljena vprašanja

Nekatera pogosta vprašanja med poskusom prepričevanja ljudi, da sprejmejo pogodbeno testiranje, vključujejo:

V # 1) Imamo že 100-odstotno pokritost s testi, zato ga ne potrebujemo.

Odgovor: No, to je nemogoče, toda pogodbeno testiranje ima še veliko drugih prednosti kot zgolj pokritost s testom.

V # 2) Odgovornost arhitekta Solution Architect je, da sporoča spremembe API-ja.

Odgovor: Kakovost je odgovornost celotne ekipe.

V # 3) Zakaj ustvarjamo testne scenarije za skupino API?

Odgovor: Skupina za API ne ve, kako deluje spletna storitev, zakaj bi bila torej odgovorna za to.

V # 4) Naši preskusi od konca do konca zajemajo celoten tok od začetka do konca, vključno z drugimi integracijskimi točkami.

Odgovor: Zakaj natančno delimo teste, da bi preizkusili eno stvar, in niste vi odgovorni, da preizkusite celovit tok sistema, za katerega ne veste, kako deluje.

V # 5) V skladišču katere ekipe živijo testi?

Odgovor: Oboje. Potrošnik v svojem skladišču in ponudnik v svojem. Nato v osrednji točki pogodba živi zunaj obeh.

Argumenti

To so argumenti, proti katerim se težko prepiramo, ko gre za prehod na pogodbo za testiranje:

  • Swaggerjeva dokumentacija je že na voljo in jo je mogoče uporabiti za ustvarjanje integracijskih testov.
  • Skupine imajo v lasti storitve front-end in back-end z učinkovitim mehanizmom za spremembe API-jev.

Stalna integracija

Kako se to ujema z vašim testnim paketom za neprekinjeno integracijo? Zaželeno mesto za pogodbeno testiranje je življenje z enotami.

Potrošniški testi tvorijo lažni strežnik, ki ne zahteva zunanjih odvisnosti zunaj testa.

Preskusi ponudnikov zahtevajo primerek API, zato je lokalni API mogoče oviti s pomočjo preskusni strežnik v pomnilniku . Če pa API-ja ni enostavno zaviti lokalno, je rešitev, ki smo jo že uporabili, tista, v kateri smo zavili okolje in v to okolje uvedli kodo kot del samodejnega preverjanja zahtev za vlečenje.

Stalna integracija

Neprekinjena integracija videa

Stalna integracija 3

(slika vir )

Zaključek

V tej vadnici smo izvedeli, kaj pomeni testiranje pogodb in kako je videti v infrastrukturi mikro storitev, in videli, kako je videti v resničnem primeru.

Spoznali smo, kako vam lahko preizkušanje pogodb pomaga, da svoje integracijsko testiranje premaknete v levo. Poleg tega smo videli, kako lahko zniža stroške vaše organizacije z zmanjšanjem časa povratnih informacij, povezanih z vprašanji integracije.

Testiranje po pogodbah ni samo orodje za tehnično preizkušanje, temveč spodbuja sodelovanje razvojnih skupin s sporočanjem sprememb in spodbujanjem testiranja kot eno enoto. Na splošno bi to moral biti predpogoj za vse, ki želijo preiti na stalno uvajanje.

NASLEDNJA Vadnica

Priporočeno branje

^