Menu

Úvod do testování smluv s příklady

introduction contract testing with examples

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

java programovací rozhovor otázky a odpovědi pro zkušené

Tento výukový program Pact Contract Testing vysvětluje, co je Consumer Tested Contract Testing, jak funguje a proč byste jej měli používat ve své strategii testování:

Co je Testování smlouvy?

Spotřebitelské testování smluv je forma testování API, která skutečně umožňuje posun doleva. Smluvní nástroj, který používáme, je Pact.io , a my se o tom dozvíme později v této sérii tutoriálů.

Smlouva testování je metoda pro nezávislé ověření integrace mezi dvěma aplikacemi, aby se otestovalo, co bylo předáno, a uvidíme, jestli to, co je vráceno, odpovídá „smlouvě“.

Testy kontraktů dobře zapadají do architektury mikroslužeb a fungují v agilním prostředí. Příklady proto budou vycházet ze zkušeností, které jsme získali při práci v tomto prostředí.

Testování smlouvy

Co se naučíte:

Seznam výukových programů v této sérii pro testování smluv

Výukový program č. 1: Úvod do testování smluv s příklady (Tento návod)
Výukový program č. 2: Jak napsat test spotřebitelské smlouvy v JavaScriptu
Výukový program č. 3: Jak publikovat smlouvu o smlouvě s paktem Broker
Výukový program č. 4: Ověřte smlouvu Pact a nepřetržité nasazení pomocí Pact CLI

Spotřebitelské testování smluv

Výchozím bodem je vaše dokumentace API, která tvoří smlouvu pro vaše testy, v tomto okamžiku obvykle vývojové týmy vezmou dokument API a vyvíjejí se proti dokumentu wiki (nebo v jakémkoli formátu, ve kterém se nachází ve vaší organizaci, jako je Word Word).

Například, webová aplikace, kde front-end vyvíjí Team Krypton a API vyvíjí Team Thoron. Projekt začíná úvodním setkáním, kde jsou požadavky představeny a odsouhlaseny mezi týmy.

Každý tým bere požadavky a začíná vytvářet nevyřízené položky vylepšováním příběhů. Vývoj začíná v obou týmech v návaznosti na uživatelské příběhy, testování integrace je ponecháno pro pozdější sprinty. Protože Team Krypton najde další požadavky týkající se chybových scénářů, je odpovídajícím způsobem aktualizována dokumentace API.

Testovací případy přidává Team Thoron týkající se aktualizovaných scénářů na základě dokumentace.

U tohoto procesu již vidíme několik nedostatků a pro štěstí jsem přidal několik dalších:

  1. Změny dokumentu API nemusí být komunikovány efektivně.
  2. Front-end tým odstraní back-end služby a naopak.
  3. Back-end tým vytváří integrační testovací případy na základě dokumentace.
  4. Integrační prostředí je poprvé, kdy je testována plná integrace.
  5. Odlišná verze API v integračním prostředí a produkci.

Spotřebitelské testování smluv má dvě strany, tj. Spotřebitele a poskytovatele. To je místo, kde se převrací tradiční myšlení o testování v mikroslužbách.

The Spotřebitel je kurátorem scénářů, včetně požadavku a očekávané odpovědi. To vám umožní sledovat Postel’s Law což vám diktuje, měli byste být flexibilní v tom, co vaše API může přijmout, ale konzervativní v tom, co se odesílá. S odvoláním na nedostatky č. 1, 3 a 4 jsou změny dokumentace řízeny spotřebitelem.

Například, za okolností, kdy Team Thoron změní pole řetězce tak, aby nepřijímalo nulové hodnoty, by spotřebitelské testy změnu neodrážely, a proto by selhaly. Nebo alespoň dokud nebyly provedeny změny v týmu Krypton.

Definujte očekávání spotřebitelů

(obraz zdroj )

The Poskytovatel ověřuje scénáře poskytované spotřebitelem proti jejich prostředí „dev“. To umožňuje vynucení vašich mikroslužeb Paralelní změna což uvádí, že byste měli rozšířit funkčnost API, následovanou migrací na novou verzi. S odkazem zpět na chybu č. 2, útržky obvykle vytvořené back-endovými týmy pro jejich vlastní požadavky na testování mohou nyní vycházet ze spotřebitelských scénářů pomocí Pact Stub Server .

Ověřte očekávání poskytovatele

Závazným prvkem obou stran je „smlouva“, kterou je třeba sdílet mezi týmy. Pakt poskytuje platformu umožňující sdílení smluv s názvem Pakt Broker (k dispozici jako spravovaná služba s Pactflow.io ).

The Makléř ukládá výstup spotřebitelských scénářů. Smlouva je poté uložena v makléři vedle verze API. To umožňuje testování proti více verzím API, takže kompatibilita může být potvrzena před vydáním, jak je zvýrazněno v chybě č. 5.

pact_network_diagram
Pact Broker - vizuální reprezentace

Další výhodou pro Pact Broker ve starších platformách je viditelnost spotřebitelů. Ne všichni spotřebitelé byli autorům API známí, zejména to není způsob jejich konzumace.

Konkrétně s odkazem na výskyt, kdy byly podporovány dvě verze API, došlo ve verzi 1 (V1) k problému s daty, kdy API způsobovalo špinavá data v databázi.

Změna byla implementována ve verzi V1 API a přesunuta do výroby, ale spotřebitel se spoléhal na formát, který způsoboval problém s daty, čímž narušil jejich integraci s API.

Jak to funguje

Tok autentizace

Výše uvedený příklad ukazuje tok ověřování, webová služba vyžaduje, aby se uživatelé ověřili, aby získali přístup k citlivým datům. Webová služba odešle žádost rozhraní API o vygenerování tokenu pomocí uživatelského jména a hesla. API vrací nosný token, který je přidán k požadavku na data jako záhlaví autentizace.

Spotřebitelský test vytvoří požadavek POST na token předáním těla s uživatelským jménem a heslem.

POST požadavek

Falešný server se roztočí během testu, který ověří vámi vytvořený požadavek, spolu s očekávanou odpovědí, která v tomto příkladu obsahuje hodnotu pro token.

falešný server

Výstup spotřebitelského testu vygeneruje soubor smlouvy smlouvy. To bude uloženo v pact brokeru jako verze 1.

Zprostředkovatel poté stáhne verzi 1 z pact brokera a přehraje tento požadavek proti jejich místnímu prostředí ověřením shody požadavku a odpovědi s požadavky spotřebitele.

pakt broker

Role a odpovědnosti

Role a odpovědnosti

Quality Assurance (QA) / Tester: Vytváření smluv pomocí Pact.io a práce s BA na generování testovacích scénářů.

Vývojář: Párování s QA při vytváření testů a pomoc při zabalení API pro implementaci v Continuous Integration (CI).

Obchodní analytik (BA): Generování scénářů a spolupráce s architektem na ověření dotčených stran.

Architekt řešení (Ve vaší organizaci nemusí existovat): Provádět změny API a koordinovat s BA při implementaci, také komunikovat změny spotřebitelům (pomocí Pact Broker pochopit, koho se to může týkat).

Správa vydání: (Ano, vím, že je to staromódní, ale v mém světě stále existuje): Naplněn jistotou, že změny budou úspěšně vydány kvůli pokrytí testováním smluv.

Celý tým: Ověřte výsledky a určete, zda lze vydání poslat do produkce pomocí nástroje Pact CLI, Mohu nasadit .

Testování kontraktů vs. Testování integrace

Aby bylo možné ověřit, zda systém funguje před povýšením do produkčního prostředí, musí existovat testování integrace, ale scénáře lze výrazně snížit.

Dopad by mohl být:

  • Rychlejší zpětná vazba před uvolněním do integračního prostředí.
  • Menší závislost na stabilitě integračního prostředí.
  • Méně prostředí podporujících více verzí API.
  • Omezené instance nestabilního prostředí kvůli problémům s integrací.
IntegraceSmlouva
Zjevně přesně určit selháníMnoho vrstevVelmi snadné
Konfigurace APIAnoNedělej
Kontroly nasazeníAnoNedělej
Správa verzí APIAnoAno
Ladit lokálněNedělejAno
Otázky životního prostředíAnoNedělej
Čas zpětné vazbyPomalýRychle

Za prvé, testování kontraktů nenahrazuje testování integrace. Ale pravděpodobně to může nahradit některé vaše stávající scénáře testování integrace, posunout doleva a poskytnout rychlejší zpětnou vazbu k vašemu životnímu cyklu vývoje softwaru.

Při testování integrace budete ověřovat kontext, ve kterém API žije, například architekturu prostředí, proces nasazení atd.

Proto chcete spouštět základní testovací scénáře, které by potvrdily konfiguraci, například, koncový bod kontroly stavu pro verzi api. Také prokázání úspěšnosti nasazení vrácením odpovědi 200.

Při testování kontraktů testujete specifika API, která zahrnuje okrajové případy související se strukturou API, obsahem (např. Hodnoty polí, klíče existují) a reakcemi na chyby. Například, zpracovává API hodnoty null nebo jsou odstraněny z odpovědi API (další skutečný příklad).

Některé výhody (pokud ještě nejste prodáni)

Níže jsou uvedeny některé výhody, z nichž je možné čerpat při prodeji smluvního testování širšímu podniku:

jak mohu otevřít soubor json?
  • Rychlejší nasazení softwaru
  • Jediný zdroj pravdy
  • Viditelnost všech spotřebitelů
  • Snadné testování proti různým verzím API.

Často kladené otázky

Některé běžné otázky při pokusu přesvědčit lidi, aby přijali testování smlouvy, zahrnují:

Otázka č. 1) Již máme 100% pokrytí testem, takže ho nepotřebujeme.

Odpovědět: To je nemožné, ale testování smlouvy má mnoho dalších výhod, než jen pokrytí testů.

Otázka č. 2) Je odpovědností architekta řešení komunikovat změny API.

Odpovědět: Kvalita je odpovědností celého týmu.

Otázka č. 3) Proč vytváříme testovací scénáře pro tým API?

Odpovědět: Tým API neví, jak webová služba funguje, tak proč by tam měla být zodpovědnost.

Otázka č. 4) Naše end-to-end testy pokrývají celý tok od začátku do konce, včetně dalších integračních bodů.

Odpovědět: Přesně proto rozdělujeme testy, abychom otestovali jednu věc, a není vaší odpovědností otestovat end-to-end tok systému, o kterém nevíte, jak funguje.

Otázka č. 5) Ve kterém týmovém úložišti testy žijí?

Odpovědět: Oba. Spotřebitel ve svém úložišti a poskytovatel ve svém. Pak v centrálním bodě smlouva žije mimo některého z nich.

Argumenty

Toto jsou argumenty, proti nimž je těžké argumentovat, pokud jde o přechod na smlouvu k testování:

  • Už je k dispozici dokumentace Swagger, kterou lze použít ke generování integračních testů.
  • Týmy vlastní služby front-end i back-end s efektivním mechanismem pro změny API.

Kontinuální integrace

Jak to zapadá do vaší testovací sady pro nepřetržitou integraci? Požadovaným místem pro testování kontraktů je testování vašich jednotek.

Spotřebitelské testy roztočí falešný server, který mimo test nevyžaduje žádné externí závislosti.

Testy poskytovatele vyžadují instanci API, proto lze místní API zabalit pomocí testovací server v paměti . Pokud však není snadné zabalit vaše API lokálně, řešení, které jsme použili dříve, je místo, kde jsme roztočili prostředí a nasadili kód do tohoto prostředí jako součást automatických kontrol vyžádání vyžádání.

Kontinuální integrace

Kontinuální integrační video

Kontinuální integrace 3

(obraz zdroj )

Závěr

V tomto kurzu jsme se dozvěděli, co testování kontraktů znamená a jak to vypadá v infrastruktuře mikroslužeb, a viděli jsme, jak to vypadá v reálném příkladu.

Získali jsme ponaučení o tom, jak vám testování kontraktů může pomoci posunout testování integrace doleva. Kromě toho jsme viděli, jak může snížit náklady vaší organizace snížením doby zpětné vazby související s problémy s integrací.

Smlouva testování není jen nástrojem pro technické testování, vynucuje spolupráci vývojových týmů tím, že komunikuje změny a podporuje testování jako jeden celek. Celkově by to mělo být předpokladem pro každého, kdo chce přejít na Continuous Deployment.

DALŠÍ výuka

Doporučené čtení

^