Úvod do testovania zmlúv s príkladmi

introduction contract testing with examples

Tento výukový program Pact Contract Testing vysvetľuje, čo je Consumer Tested Contract Testing, ako funguje a prečo by ste ho mali používať vo svojej stratégii testovania:

Čo je to Testovanie zmlúv?

Spotrebiteľsky motivované testovanie zmlúv je forma testovania API, ktorá skutočne umožňuje posun vľavo. Zmluvný nástroj, ktorý používame, je Pact.io , a o tom sa dozvieme neskôr v tejto sérii tutoriálov.

Zmluvné testovanie je metóda na nezávislé overenie integrácie medzi dvoma aplikáciami s cieľom otestovať, čo prešlo, a zistiť, či sa vrátené zhoduje s „zmluvou“.

Zmluvné testy zapadajú do architektúry mikroslužieb a fungujú v svižnom prostredí. Príklady preto budú založené na skúsenostiach, ktoré sme získali pri práci v tomto prostredí.

Čo sa dozviete:

• Zoznam návodov v tejto sérii na testovanie zmlúv
• Spotrebiteľsky testované zmluvy
  • Ako to funguje
  • Úlohy a zodpovednosti
• Testovanie zmlúv vs Testovanie integrácie
  • Niektoré výhody (ak ešte nie ste predané)
  • často kladené otázky
• Nepretržitá integrácia
• Záver
  • Odporúčané čítanie

Zoznam návodov v tejto sérii na testovanie zmlúv

Výukový program č. 1: Úvod do testovania zmlúv s príkladmi (Tento návod)
Výukový program č. 2: Ako napísať test spotrebiteľskej zmluvy v JavaScripte
Výukový program č. 3: Ako zverejniť paktovú zmluvu pre sprostredkovateľa Pact
Výukový program č. 4: Overte zmluvu Pact a nepretržité nasadenie pomocou Pact CLI

Spotrebiteľsky testované zmluvy

Východiskovým bodom je vaša dokumentácia API, ktorá tvorí zmluvu pre vaše testy. V tomto okamihu zvyčajne vývojové tímy vezmú dokument API a vyvíjajú ho proti dokumentu wiki (alebo akémukoľvek formátu, ktorý sa nachádza vo vašej organizácii, napríklad Word Word).

Napríklad, webová aplikácia, kde front-end vyvíja tím Krypton a API vyvíja tím Thoron. Projekt začína úvodným stretnutím, kde sú požiadavky predstavené a dohodnuté medzi tímami.

Každý tím vezme požiadavky a začne vytvárať nevybavené položky vylepšovaním príbehov. Vývoj začína v obidvoch tímoch podľa používateľských príbehov, testovanie integrácie je ponechané na ďalšie sprinty. Keď Team Krypton zistí ďalšie požiadavky týkajúce sa chybových scenárov, dokumentácia API sa zodpovedajúcim spôsobom aktualizuje.

Testovacie prípady pridáva Team Thoron týkajúce sa aktualizovaných scenárov založených na dokumentácii.

Už teraz môžeme vidieť niekoľko nedostatkov tohto procesu a pre šťastie som pridal niekoľko ďalších:

1. Zmeny dokumentu API nemusia byť komunikované efektívne.
2. Front-end tím odstraňuje back-end služby a naopak.
3. Back-end tím vytvára integračné testovacie prípady na základe dokumentácie.
4. Integračné prostredie je prvýkrát, čo sa testuje úplná integrácia.
5. Odlišná verzia API pre integračné prostredie a produkcia.

Testovanie zmlúv na základe spotrebiteľa má dve strany, tj. Spotrebiteľ a poskytovateľ. To je miesto, kde sa prevracia tradičné myslenie o testovaní v mikroslužbách.

The Spotrebiteľ je kurátorom scenárov vrátane požiadavky a očakávanej odpovede. To vám umožňuje sledovať Posteľ 's Law podľa ktorého by ste mali byť flexibilní v tom, čo môže vaše API akceptovať, ale konzervatívni v tom, čo sa posiela. S odvolaním sa na chyby č. 1, 3 a 4, zmeny dokumentácie riadi spotrebiteľ.

Napríklad, za okolností, keď Team Thoron zmení pole reťazca tak, aby neprijímalo nulové hodnoty, spotrebiteľské testy by zmenu neodrážali, a preto by zlyhali. Alebo aspoň dovtedy, kým nedošlo k zmenám v tíme Krypton.

(obrázok zdroj )

The Poskytovateľ overuje scenáre poskytované spotrebiteľom v porovnaní s ich prostredím „dev“. To umožňuje presadzovať vaše mikroslužby Paralelná zmena v ktorom sa uvádza, že by ste mali rozšíriť funkčnosť rozhrania API a následne prejsť na novú verziu. S odvolaním sa na chybu č. 2, útržky zvyčajne vytvorené back-endovými tímami pre ich vlastné požiadavky na testovanie môžu byť teraz založené na spotrebiteľských scenároch pomocou Pact Stub Server .

Záväzným prvkom oboch strán je „zmluva“, ktorú je potrebné zdieľať medzi tímami. Pakt poskytuje platformu umožňujúcu zdieľanie zmlúv s názvom Pakt Broker (k dispozícii ako spravovaná služba s Pactflow.io ).

The Sprostredkovateľ ukladá výstupy zo spotrebiteľských scenárov. Zmluva je potom uložená v sprostredkovateľovi spolu s verziou API. To umožňuje testovanie na viacerých verziách API, takže kompatibilita môže byť potvrdená pred vydaním, ako je zdôraznené v chybe č. 5.

Ďalšou výhodou Pact Broker v starších platformách je viditeľnosť spotrebiteľov. Nie všetci spotrebitelia boli autorom API známi, najmä to nie je tak, ako sa konzumuje.

Konkrétne ide o výskyt, pri ktorom boli podporované dve verzie API, vo verzii 1 (V1) došlo k problému s údajmi, ktorý spôsobovalo API špinavé dáta v databáze.

Zmena bola implementovaná vo V1 API a presunutá do výroby. Spotrebiteľ sa však spoliehal na formát, ktorý spôsoboval problém s údajmi, čím sa narušila ich integrácia s API.

Ako to funguje

Vyššie uvedený príklad ukazuje postup autentifikácie, webová služba vyžaduje od používateľov autentifikáciu, aby mohli získať prístup k citlivým údajom. Webová služba odošle požiadavku na API na vygenerovanie tokenu pomocou používateľského mena a hesla. API vráti nosný token, ktorý sa pridá k požiadavke na údaje ako autentifikačná hlavička.

Spotrebiteľský test vytvorí požiadavku POST na token odovzdaním tela s používateľským menom a heslom.

Počas testu sa naštartuje falošný server, ktorý overí vami vytvorenú požiadavku, spolu s očakávanou odpoveďou, ktorá v tomto príklade obsahuje hodnotu pre token.

Výstupom zo spotrebiteľského testu je paktový zmluvný súbor. Toto bude uložené v paktovom makléri ako verzia 1.

Poskytovateľ potom stiahne verziu 1 od sprostredkovateľa paketov a prehrá túto požiadavku oproti miestnemu prostrediu overením, či sa požiadavka a odpoveď zhodujú s požiadavkami zákazníka.

Úlohy a zodpovednosti

Zabezpečenie kvality (QA) / Tester: Vytváranie zmlúv pomocou Pact.io a spolupráca s BA na generovaní testovacích scenárov.

Vývojár: Párovanie s QA pri vytváraní testov a pomoc pri zabalení API pre implementáciu v Continuous Integration (CI).

Obchodný analytik (BA): Generovanie scenárov a spolupráca s architektom na overení dotknutých strán.

Architekt riešení (Vo vašej organizácii nemusí existovať): Vykonávanie zmien API a koordinácia s BA pri implementácii, tiež komunikácia zmien spotrebiteľom (pomocou Pact Broker pochopíte, koho sa to môže týkať).

Správa vydaní: (Áno, viem, že je to staromódne, ale v mojom svete stále existuje): Plný dôvery, že zmeny budú úspešne vydané vďaka pokrytiu testovaním zmlúv.

Celý tím: Overte výsledky a zistite, či je možné vydania tlačiť do výroby pomocou nástroja Pact CLI, Môžem nasadiť .

Testovanie zmlúv vs Testovanie integrácie

Musí existovať testovanie integrácie, aby sa dalo overiť, či systém funguje pred povýšením do produkčného prostredia, ale scenárov je možné výrazne obmedziť.

Môže to mať vplyv:

aký je bezpečnostný kľúč na bezdrôtovom smerovači

• Rýchlejšia spätná väzba pred uvoľnením do integračného prostredia.
• Menšie spoliehanie sa na stabilitu integračného prostredia.
• Menej prostredí podporujúcich viac verzií API.
• Zníženie výskytu nestabilných prostredí v dôsledku problémov s integráciou.

Po prvé, testovanie zmlúv nenahrádza testovanie integrácie. Pravdepodobne však môže nahradiť niektoré vaše existujúce scenáre testovania integrácie, posunúť sa doľava a poskytnúť rýchlejšiu spätnú väzbu k vášmu životnému cyklu vývoja softvéru.

Pri testovaní integrácie budete overovať kontext, v ktorom API žije, napríklad architektúru prostredia, proces nasadenia atď.

Preto chcete spustiť základné testovacie scenáre, ktoré by potvrdili konfiguráciu, napríklad, koncový bod kontroly stavu pre verziu api. Preukázanie úspešnosti nasadenia vrátením odpovede 200.

Pri testovaní zmlúv testujete špecifiká API, ktoré zahŕňajú okrajové prípady súvisiace so štruktúrou API, obsahom (napr. Existujú hodnoty polí, kľúče) a reakciami na chyby. Napríklad, spracováva API nulové hodnoty alebo sú odstránené z odpovede API (ďalší skutočný príklad).

Niektoré výhody (ak ešte nie ste predané)

Nižšie sú uvedené niektoré výhody, z ktorých je možné čerpať pri predaji testovania zmlúv širšiemu podnikaniu:

• Rýchlejšie nasadenie softvéru
• Jediný zdroj pravdy
• Viditeľnosť všetkých spotrebiteľov
• Ľahké testovanie na rôznych verziách API.

často kladené otázky

Medzi niektoré bežné otázky, ktoré sa snažia presvedčiť ľudí, aby prijali testovanie zmlúv, patria:

Otázka č. 1) Už máme 100% pokrytie testami, takže ho nepotrebujeme.

Odpoveď: To je nemožné, ale testovanie zmlúv má mnoho ďalších výhod, než len pokrytie testami.

Otázka č. 2) Je zodpovednosťou architekta riešenia komunikovať zmeny API.

Odpoveď: Za kvalitu je zodpovedný celý tím.

Otázka 3) Prečo vytvárame testovacie scenáre pre tím API?

Odpoveď: Tím API nevie, ako webová služba funguje, tak prečo by tam mala byť zodpovednosť?

Otázka č. 4) Naše end-to-end testy pokrývajú celý tok od začiatku do konca, vrátane ďalších integračných bodov.

Odpoveď: Presne preto rozdeľujeme testy tak, aby sme otestovali jednu vec, a nie je vašou zodpovednosťou otestovať komplexný tok systému, o ktorom neviete, ako funguje.

Otázka č. 5) V ktorom tímovom úložisku žijú testy?

Odpoveď: Oboje. Spotrebiteľ v ich úložisku a poskytovateľ v ich. Potom v centrálnom bode zmluva žije mimo jedného z nich.

Argumenty

Toto sú argumenty, proti ktorým je ťažké argumentovať, pokiaľ ide o prechod na zmluvu na testovanie:

• Už existuje dokumentácia Swagger, ktorú je možné použiť na generovanie integračných testov.
• Tímy vlastnia front-end aj back-end služby s efektívnym mechanizmom na zmeny API.

Nepretržitá integrácia

Ako to zapadá do vašej testovacej sady na nepretržitú integráciu? Požadovaným miestom pre testovanie na základe zmluvy je testovanie vašich jednotiek.

Spotrebiteľské testy roztiahnu falošný server, ktorý mimo testu nevyžaduje žiadne externé závislosti.

Testy poskytovateľa vyžadujú inštanciu API, preto je možné lokálne API zabaliť pomocou testovací server v pamäti . Ak však nie je ľahké zabaliť vaše API lokálne, riešením, ktoré sme použili predtým, je miesto, kde sme roztočili prostredie a nasadili kód do tohto prostredia ako súčasť automatických kontrol vyžiadania načítania.

(obrázok zdroj )

Záver

V tomto tutoriáli sme sa dozvedeli, čo znamená testovanie zmlúv a ako to vyzerá v mikroslužobnej infraštruktúre, a videli sme, ako to vyzerá na príklade z reálneho sveta.

Získali sa lekcie o tom, ako vám testovanie zmlúv môže pomôcť posunúť testovanie integrácie doľava. Okrem toho sme videli, ako môže znížiť náklady vašej organizácie znížením časov spätnej väzby súvisiacich s problémami s integráciou.

Zmluvné testovanie nie je iba nástrojom na technické testovanie, ale vynucuje spoluprácu vývojových tímov komunikáciou zmien a podporou testovania ako jednej jednotky. Celkovo by to malo byť nevyhnutným predpokladom pre každého, kto chce prejsť na kontinuálne nasadenie.

NEXT Tutorial

Odporúčané čítanie

• Ako napísať test spotrebiteľskej zmluvy v JavaScripte
• Overte zmluvu Pact a nepretržité nasadenie pomocou Pact CLI
• Ako zverejniť paktovú zmluvu pre sprostredkovateľa Pact
• Proces nepretržitej integrácie: Ako zlepšiť kvalitu softvéru a znížiť riziko
• Rozdiely medzi testovaním jednotiek, testovaním integrácie a funkčným testovaním
• Čo je testovanie integrácie (návod s príkladom testovania integrácie)
• Najlepšie 10 nástrojov na testovanie integrácie na zápis testov integrácie
• Nepretržité nasadenie v DevOps