Tu je návod, ako testuje externé API v Elixire s Bypass

Uprednostňujeme princípy architektúry orientovanej na služby na adrese obrátený, To znamená, že máme malé, udržateľné komponenty s jasne definovanými povinnosťami. Komunikujú medzi sebou (väčšinou) prostredníctvom reprezentatívnych štátnych prevodov, alebo REST, API.

To poskytuje flexibilitu a poslúžilo nám dobre s výnimkou jednej významnej stránky: Testovanie. Pri testovaní sa treba vyhnúť:

• Závislosť na externých službách bežiacich na rovnakom stroji.
• Pomalé testy.

Pretože aplikácie sa vo svojej podstate spoliehajú na externé služby, je dôležité mať pre tieto závislosti zavedenú testovaciu stratégiu.

Nedávno sme začali používať Bypass a vysvetlím, ako sme tam prišli a ako konkrétne ho používame.

Minulosť

Metódy Mock a vrátenie niektorých príkladov údajov ako je tento:

To bolo (a verím, že stále je) „cesta“ vo svete Ruby / Rails. Bohužiaľ, toto podporuje zlé správanie, ako to najlepšie vysvetľuje José Valim.

Potom sme začali používať ExVCR, čo je skvelá knižnica, ale má podobné nevýhody ako mocks / stubs: Podporuje lenivosť a nepodporuje oddelenie záujmov, ktoré sú rozhodujúce pre dobre definované API. ExVCR umožňuje reálne živé dáta „nahrávať“ a „prehrávať“. Integrácia je veľmi jednoduchá (vrátane niekoľkých riadkov vo vašom teste a všetko ostatné je postarané). Ale v ideálnom prípade musíte premýšľať o externých závislostiach v testoch, nie abstraktných. Pre scenáre môže byť stále životaschopnou voľbou, keď sa má test koncového bodu testovať s minimálnou réžiou (používame ho na testovanie volaní služby Amazon AWS Services ako S3).

Zadajte adaptéry

Adaptéry fungujú skvele a podporujú diskusiu o zmluvách API a jasne definované hranice komunikácie. Tento prístup stále používame, najmä ak je Adaptér zložitejší (napríklad zásuvka JSON-RPC).

Takto môže vyzerať adaptér:

Ale pre jednoduché koncové body HTTP, adaptéry vyzerajú ako veľa práce a majú hlavnú nevýhodu: opúšťajú knižnice, ktoré spotrebujú, z testovacej rovnice. Ak sa niečo zmení v knižniciach HTTP alebo JSON, testy ich nezachytia. Množstvo produkčne kritického kódu, ktorý tento prístup neoveril, je neprijateľné.

Súčasnosť a budúcnosť

Bypass nám umožňuje spustiť veľmi jednoduchý webový server v testoch, ktoré simulujú externé služby, ktoré používame.

Teraz môžeme otestovať celý zásobník, vrátane knižnice HTTP, knižnice kódovania / dekódovania JSON a mechanizmov autentifikácie. Obchádzka README je dobre napísaná, takže budem šetriť detaily implementácie. Mierne však meníme spôsob, akým ich používame, aby boli testy stručné a čitateľné:

Po prvé, niekedy chceme volať na Facebook, keď sú testy spustené ako úplná integračná sada. Robíme to nepravidelne, aby sme zabezpečili, že Facebook API bude stále fungovať podľa našich očakávaní. pridanie - zahrnúť integráciu na mix test nesimuluje API, ale namiesto toho volá na externú službu (riadky 5, 7).

Sme explicitné, keď simulujeme požiadavky na externé služby, takže každý test, ktorý používa Bypass, musí mať @tag facebook_bypass (riadok 7).

Nakoniec handle_fb (riadky 30 - 39) sa volajú (dané, že. t request_path zápasy). Páči sa mi, aby som si v hlave funkcie zladil, pretože presne určuje, na ktorú cestu reagujeme a umožňuje nám definovať rôzne funkcie pre rôzne cesty.

Takže Bypass beží iba na testoch označených @tag: bypass a keď nie sme v prevádzke náš integračný balík. Ešte jedna vec, ktorú robíme pri nastavovaní Bypassu, je umožniť tagu prejsť id stránky (riadky 8, 20). Tak tu je, ako test, ktorý používa Bypass vyzerá v celej jeho sláve:

Ako vidíte, facebook_bypass je to explicitné, že simulujeme API (pokiaľ nie sme v integračnom režime). Umožňuje nám odovzdať informácie do simulovaného rozhrania API a pre rôzne testy je veľmi jednoduché znova použiť rovnakú konfiguráciu Bypass.

Dúfam, že vám to pomôže otestovať externé rozhrania API. Ak máte ďalšie otázky, môžete ma nájsť na Twitteri (pozri nižšie).