wiremock tutorial introduction wiremock
Tento úvodný videonávod vysvetlí funkcie programu Wiremock a spôsob spustenia programu Wiremock ako samostatného servera a ako súčasť testov JUnit:
V tomto výučbe sa budeme venovať základným pojmom a detailom okolo nástroja Wiremock. Môže byť použitý ako samostatný server HTTP, ako aj v rámci testov JUnit podľa požiadaviek.
Toto je často používaný nástroj, pretože je open-source a má veľkú komunitu prispievateľov. Spadá do kategórie nástrojov virtualizácie služieb.
Čo sa dozviete:
Čo je Wiremock?
Zjednodušene povedané, Wiremock je zosmiešňujúcim nastavením integračných testov. Je to jednoducho falošný server, ktorý je vysoko konfigurovateľný na vrátenie očakávanej odpovede na danú požiadavku.
Je široko používaný počas vývoja a hlavne počas testovania integrácie, zatiaľ čo systém alebo služba hovorí s jednou alebo viacerými externými alebo internými závislosťami / službami.
Skúsme pochopiť viac informácií o testovaní integrácie všeobecne a zistíme, ako môže Wiremock pomôcť prekonať tieto výzvy a uľahčiť náš život.
Spravidla, keď dôjde k slovu integrácia, čo nás zarazí, je integrácia typu end to end medzi dvoma komunikujúcimi systémami. Teraz sa na to pozrime z pohľadu testovanej aplikácie, ktorá na vykonanie úlohy využíva niektoré externé služby.
Napríklad, Predpokladajme, že budujeme aplikáciu pre online cestovný systém alebo systém predaja cestovných lístkov a že máme modul na kontrolu stavu PNR, ktorý zasahuje externé API poskytované spoločnosťou Indian Railways.
Ako teraz môžeme testovať integráciu našej aplikácie s externými API?
Môžete to urobiť dvoma spôsobmi:
- Najprv, je prístup založený na testovaní jednotiek, pri ktorom zakryjeme rozhranie, ktoré je poskytované (alebo vytvorené vo vlastnej réžii), aby náš systém otestoval / overil zablokovanú alebo falošnú odpoveď ešte predtým, ako narazíte na externé API. Toto nie je nič iné ako test jednotky, ktorý sa pokúša zosmiešniť externú závislosť.
- Druhý testuje externé závislosti pomocou nejakého testovacieho prostredia (alebo skutočného produkčného prostredia). Existuje však niekoľko výziev, ktoré s týmto prístupom vyplývajú, spomenuté nižšie:
- Externé systémy API nemusia byť vždy k dispozícii. tj. sme veľmi závislí alebo závislí od externých systémov a akýkoľvek výpadok tam bude mať vplyv na naše testy a nepriamo na proces vývoja / vydania.
- Po druhé, externé API môžu, ale nemusia mať testovacie prostredie. Napríklad, rozhranie API na kontrolu stavu PNR môže na načítanie a vrátenie odpovedí vždy vyžadovať skutočné čísla PNR.
- Zasiahnutie API často stojí náklady. Napríklad, Predpokladajme, že API na kontrolu PNR účtuje 100 R za každých 1 000 požiadaviek. Pretože integračné testy sa zvyčajne spúšťajú pri každej regresii (a väčšinou pri každom potvrdení), nemusí byť nákladovo efektívne riešenie zasiahnuť také rozhranie API, ktoré nás stojí dokonca aj na účely testovania.
- Nie je možné nakonfigurovať externé API, aby vrátilo požadovanú odpoveď. Aj keď je to možné, budete musieť vytvoriť veľa testovacích údajov, aby ste zabezpečili rôzne odpovede na rôzne vstupy požiadaviek.
Napríklad, chcete otestovať chybové scenáre, napríklad API vracia rôzne stavové kódy pre rôzne typy údajov. Pretože odpoveď nie je pod našou kontrolou, budeme musieť vytvoriť viac súborov údajov na overenie rôznych možných scenárov alebo výsledkov.
Pochopme tieto pojmy pomocou nasledujúceho diagramu.
Tu porovnávame obidva prístupy integračného testovania, tj. Bez falošného servera s použitím skutočnej implementácie externej závislosti a s použitím falošného servera (Wiremock), ktorý sa vysmieva odpovediam na prijaté žiadosti o závislosť.
V druhom prípade výrazne znižuje závislosť a závislosť od skutočnej implementácie závislosti a poskytuje veľa konfiguračných schopností bez toho, aby bola ohrozená kvalita a dodacie plány.
Ako reaguje Wiremock na danú žiadosť?
Ako vieme, Wiremock je programový Mock server, ktorého reakcia na danú požiadavku spočíva v ukladaní všetkých relevantných mapovaní (alebo zosmiešňovaných odpovedí) do priečinka s názvom „mapovania“.
Existuje komponent porovnávača Wiremock, ktorý spáruje prichádzajúce požiadavky s uloženými mapovaniami a ak sa vráti úspešná zhoda, potom sa vráti prvá takáto zhoda ako odpoveď na danú požiadavku.
Ak používate samostatnú verziu Wiremocku, po spustení servera Wiremock uvidíte priečinok mapovania, ktorý sa vytvorí v adresári Wiremock install / jar location.
Výukové video: Úvod do nástroja Wiremock
ako obrátiť pole v jave -
Ako používať Wiremock?
Teraz sa pozrime, ako môžeme tento nástroj použiť v našich integračných testoch.
Môže sa použiť nasledujúcimi spôsobmi.
Samostatný server Wiremock
Ako samostatný server môžete jednoducho vytvoriť jednoduchú aplikáciu Java so závislosťou Maven / Gradle pre Wiremock a ponechať ju ako spustený proces.
Toto je dobrá alternatíva, ak chcete hosťovať na samostatnom serveri na nejakom stroji a použiť ho ako jeden simulovaný server pre celý projekt alebo tím. V samostatnom režime je možné tento nástroj spustiť aj stiahnutím dostupnej samostatnej nádoby tu a jednoducho spustite nádobu.
Napríklad, Predpokladajme, že chcete nasadiť svoju samostatnú inštanciu Wiremock na nejaký server v cloude alebo na lokálnom serveri, potom môžete jednoducho spustiť tento jar a použiť systémovú IP na jeho použitie ako hostenej služby.
Pozrime sa kroky na spustenie v samostatnom režime (a konfigurácia rôznych vecí, ako sú porty, mapovacie priečinky atď.)
# 1) Spustite nádobu Wiremock z terminálu (alebo príkazového riadku pre používateľov systému Windows) ako ktorýkoľvek iný súbor JAR (z inštalačného adresára nádoby Wiremock).
java -jar wiremock-standalone-2.25.1.jar
#dva) V predvolenom nastavení beží Wiremock na localhost: 8080 (ak je port voľný na použitie, potom vyššie uvedený príkaz spustí server Wiremock v samostatnom režime) a uvidíte výstup uvedený nižšie.
# 3) Teraz, keď sa server spustí, môžete navštíviť ktorúkoľvek adresu URL na localhost: 8080
Napríklad, http: // localhost: 8080 / get / user / 1 - Pretože v súčasnosti nie sú nastavené žiadne falošné oznámenia, dostanete odpoveď, ako je uvedené nižšie.
# 4) Skúsme teraz pre túto adresu URL nastaviť jednoduchý stub / falošný pokus a skúste adresu URL znova stlačiť. Potom overíme, že kliknutie na rovnakú adresu URL teraz vracia vysmievanú alebo zablokovanú odpoveď.
curl -X POST --data '{ 'request': { 'url': '/get/user/1', 'method': 'GET' }, 'response': { 'status': 200, 'body': 'Here it is!
' }}' http://localhost:8080/__admin/mappings/new
Skúsme najskôr porozumieť tejto požiadavke CURL:
- Robíme požiadavku CURL POST na http: // localhost: 8080 / __ admin / mappings / new - toto je miesto, kde budú uložené všetky mapovania pre server Wiremock, ktorý sme vykonali / spustili prostredníctvom súboru JAR.
- V žiadosti Curl definujeme parametre žiadosti ako - URL a metóda požiadavky spolu s telom odpovede v sekcii „odpoveď“. To jednoducho znamená, že kedykoľvek GET požiadavka príde s URL / get / user / 1, potom odpovedzte so zadaným telom odpovede.
# 5) Keď je nastavená stubbed odpoveď (pomocou vyššie uvedenej požiadavky na zvlnenie), môžeme skúsiť zasiahnuť URL a zistiť, či dostávame späť stubbed odpoveď z Wiremocku.
Skúsme v prehliadači kliknúť na túto adresu URL - http: // localhost: 8080 / get / user / 1
Ak bolo mapovanie úspešne nastavené, mali by ste dostať odpoveď, ako je uvedené nižšie:
Spolu s testami JUnit ako konfiguráciou pravidla JUnit
Server Wiremock je možné použiť s testami JUnit ako nastavenie pravidla JUnit. Vďaka tomu sa JUnit stará o životný cyklus Wiremock, t. J. Wiremock sa spúšťa a zastavuje.
ako písať testovacie prípady v qa
Väčšinou sa používa v nastaveniach, kde by ste chceli server po každom teste spustiť a zastaviť.
To má svoje výhody v tom, že je izolovaný, a má vysoký stupeň konfigurovateľnosti na rozdiel od samostatného nastavenia, v ktorom môže viac ľudí skončiť pri použití rovnakého servera a prekračovať vzájomne blokované odpovede.
Pozrime sa na praktický príklad tohto prístupu:
# 1) Vytvorte pravidlo JUnit pre server Wiremock. Tento krok je v podstate ako krok nastavenia testu, keď bežcovi JUnit hovoríme, aby pred každým testom vytvoril inštanciu servera Wiremock a po každom teste server zastavil.
To tiež znamená, že bežec JUnit sa postará o spustenie a zastavenie servera Wiremock bez toho, aby to výslovne urobil.
@Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080));
#dva) Teraz napíšeme náš test, kde najskôr vytvoríme nášho klienta (pomocou okHttp) na vykonávanie požiadaviek proti požadovanému koncovému bodu.
// execute request through http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build();
# 3) Tu si však môžete všimnúť, že pre našu inštanciu Wiremock sme stále nenastavili vrátenie žiadneho pahýľa. tj vyššie uvedený klient bude požadovať adresu URL http: // localhost: 8080 / test / abc, ktorá nemá nakonfigurovaný stub. V takom prípade server Wiremock nevráti žiadny obsah 404.
# 4) Teraz, aby sme nastavili stub pre vyššie uvedenú adresu URL pre našu inštanciu servera Wiremock, budeme musieť zavolať statické metódy stubu Wiremocku, ako je uvedené nižšie.
private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); }
Tu vidíte, že sme použili niekoľko statických metód, ako sú configureFor, stubFor atď. Všetky tieto metódy sú súčasťou knižnice Java Wiremock. (Na tieto metódy sa pozrieme podrobne v našom ďalšom návode / sekciách)
# 5) Teraz, keď je krok konfigurácie hotový, môžeme požiadavku jednoducho vykonať prostredníctvom klienta a overiť odpoveď (v závislosti od toho, čo je nakonfigurované pre návrat pahýľa cez Wiremock)
Ak to zhrnieme, takto by vyzerala celá ukážka kódu:
public class WiremockJunitTest { @Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080)); @Test public void assertWiremockSetup() throws IOException { // Arrange - setup wiremock stubs configureStubs(); // execute request through the http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build(); // Act - call the endpoint Response response = client.newCall(request).execute(); // Assert - verify the response assertEquals('Test success!', response.body().string()); verify(exactly(1),getRequestedFor(urlEqualTo('/test/abc'))); } // configure stubs for wiremock private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); } }
Vyžadujú sa závislosti
Je k dispozícii ako:
- Samostatný súbor JAR obsahujúci iba závislosť Wiremock.
- Tučná nádoba obsahujúca Wiremock a všetky jeho závislosti.
Obe príchute sú k dispozícii ako závislosti Gradle a Maven. Viac podrobností nájdete v oficiálnom úložisku Maven tu
Videonávod: Wiremock s testom JUnit
Záver
V tomto tutoriáli sme sa oboznámili so základnými vlastnosťami programu Wiremock a zistili sme, ako ho možno spustiť ako samostatný server a ako súčasť testov JUnit pomocou pravidiel JUnit.
Krátko sme sa dotkli aj pichnutia a podrobne sa im budeme venovať v našom ďalšom návode.
NEXT Tutorial
Odporúčané čítanie
- Úvod do aplikácie Micro Focus LoadRunner - Testovanie zaťaženia s príručkou LoadRunner č. 1
- Výukový program Ngrok: Stručný úvod do inštalácie a nastavenia
- Výukový program TestNG: Úvod do rámca TestNG
- Úvod do softvéru Selenium WebDriver - Výučba selénu č. 8
- Úvod do programovacieho jazyka Java - videonávod
- Proces predstavenia a inštalácie Pythonu
- Čo je Unix: Stručný úvod do systému Unix
- Výukový program pre Neoload: Úvod do systému Neoload, sťahovanie a inštalácia