Íme, hogyan teszteli a külső API-kat az Elixirben a Bypass-el

A Szolgáltatásorientált építészet elveit prioritásként kezeljük fordítottja. Ez azt jelenti, hogy kicsi, karbantartható komponenseink vannak egyértelműen meghatározott feladatokkal. Ezek egymással kommunikálnak (többnyire) a reprezentatív állapotátvitel vagy a REST API-k segítségével.

Ez rugalmasságot biztosít és jól szolgált számunkra, kivéve az egyik jelentős szempontot: tesztelés. A tesztelés során kerülni kell:

• Az ugyanazon a gépen futó külső szolgáltatásoktól való függőség.
• Lassú tesztek.

Mivel az alkalmazások eredetileg külső szolgáltatásokra támaszkodnak, kritikus fontosságú, hogy egy tesztstratégia legyen érvényben ezekhez a függőségekhez.

Nemrégiben elkezdtük használni a Bypass-ot, és elmagyarázom, hogyan érkeztünk oda, és kifejezetten hogyan használjuk fel.

A múlt

Modellezési módszerek és néhány ilyen példaadatok:

Ez volt (és azt hiszem, még mindig) a Ruby / Rails világában az út. Sajnos ez elősegíti a rossz viselkedést, amit José Valim legjobban magyaráz.

Ezután elkezdtük használni az ExVCR-t, ami egy nagyszerű könyvtár, de hasonló hátrányokkal rendelkezik, mint a mock / stubs: Ez ösztönzi a lustaságot és nem támogatja a jól meghatározott API-k szempontjából kritikus szempontok elválasztását. Az ExVCR lehetővé teszi a valós idejű adatok „rögzítését” és „lejátszását”. Nagyon könnyen integrálható (beleértve néhány sort a tesztben, és minden más gondoskodik). De ideális esetben meg kell gondolni a külső függőségeket a tesztekben, nem pedig elvonni őket. A forgatókönyvek esetében még akkor is életképes választás lehet, ha a végpont viselkedését minimális fölérendeltséggel kell tesztelni (az Amazon AWS szolgáltatásaihoz hasonló hívások tesztelésére használjuk, mint az S3).

Adja meg az Adaptereket

Az adapterek nagyszerűen működnek, és elősegítik az API szerződésekkel és a világosan meghatározott kommunikációs határokkal kapcsolatos tanácskozást. Ezt a megközelítést még mindig használjuk, különösen akkor, ha az adapter összetettebb (mint a JSON-RPC aljzat).

Így nézhet ki az Adapter:

Az egyszerű HTTP-végpontok esetében azonban az Adapterek sok munkának tűnnek, és nagy hátrányuk van: elhagyják a könyvtárakat, amelyeket kihasználnak a tesztelési egyenletből. Ha bármi változik a HTTP vagy a JSON könyvtárakban, a tesztek nem fogják elkapni. Elfogadhatatlan a termelés-kritikus kód mennyisége, amelyet ez a megközelítés nem tesztel.

A jelen és a jövő

A bypass lehetővé teszi, hogy egy nagyon egyszerű webkiszolgálót indítsunk olyan tesztekben, amelyek a külső szolgáltatásokat szimulálják.

Most tesztelhetjük a teljes stacket, beleértve a HTTP könyvtárat, a JSON kódoló / dekódoló könyvtárat és a hitelesítési mechanizmusokat. A bypass README jól meg van írva, ezért a végrehajtási részleteket megtartom. Azonban kissé megváltoztatjuk, hogyan használjuk azt, hogy a teszteket tömören és olvashatóan tartsuk:

Először is, néha ki akarunk hívni a Facebook-ot, ha a teszteket teljes integrációs csomagként futtatjuk. Ezt szabálytalanul végezzük annak érdekében, hogy a Facebook API továbbra is elvárásaink szerint működjön. hozzáadása - tartalmazza az integrációt nak nek keverék teszt nem szimulálja az API-t, hanem felhívja a külső szolgáltatást (5., 7. sor).

Kifejezettek vagyunk, amikor külső szolgáltatásokra irányuló kéréseket szimulálunk úgy, hogy minden Bypass-ot használó tesztnek rendelkeznie kell a @tag facebook_bypass (7. sor).

Végül a handle_fb függvényt (30–39. sor) hívják (mivel a request_path mérkőzések). Szeretem a funkciófejet illeszteni, mivel kifejezi, hogy melyik utat reagáljuk, és lehetővé teszi számunkra, hogy különböző funkciókat definiáljunk különböző útvonalakhoz.

A Bypass csak a tesztelt címkékkel működik @tag: bypass és mikor nem futtatjuk integrációs csomagunkat. Egy további dolog, amit a bypass beállításakor teszünk lehetővé, lehetővé téve, hogy a címke átadjon egy oldalazonosítót (8, 20 sorok). Tehát itt van, hogy egy olyan teszt, amely Bypass-ot használ, az egész dicsőségében néz ki:

Mint látható, a facebook_bypass a tag egyértelművé teszi, hogy szimuláljuk az API-t (kivéve, ha integrációs módban vagyunk). Ez lehetővé teszi számunkra, hogy átadjuk az információt a szimulált API-nak, és nagyon egyszerű újrahasznosítani ugyanazt a Bypass konfigurációt különböző tesztekhez.

Remélem, ez segít külső API-k tesztelésében. Ha további kérdése van, keresse meg a Twitteren (lásd alább).