Så här testar du externa API i Elixir med bypass

Vi prioriterar Service Oriented Architecture Principles på Omvänd. Det betyder att vi har små, underhållbara komponenter med klart definierat ansvar. De kommunicerar med varandra (mestadels), via Representational State Transfer, eller REST, API.

Detta ger flexibilitet och har tjänat oss bra med undantag för en signifikant fasett: Testning. Vid testning bör man undvika:

• Beroende på externa tjänster som körs på samma maskin.
• Långsamma tester.

Eftersom applikationer i sig bygger på externa tjänster är det viktigt att ha en teststrategi på plats för dessa beroende.

Vi började nyligen använda Bypass och jag kommer att förklara hur vi kom dit och specifikt hur vi använder den.

Det förflutna

Mock metoder och returnera några exempel data som denna:

Det var (och jag tror fortfarande) "vägen att gå" i Ruby / Rails värld. Tyvärr främjar detta dåligt beteende som bäst förklaras här av José Valim.

Vi började sedan använda ExVCR, vilket är ett bra bibliotek, men har liknande nackdelar som mocks / stubbar: Det uppmuntrar lathet och främjar inte separation av problem som är kritiska för väldefinierade API. ExVCR gör att man kan "spela in" och "spela upp" live-live-data. Det är väldigt lätt att integrera (inklusive några rader i ditt test och allt annat tas hand om). Men idealt måste man tänka på externa beroenden i test, inte abstrahera dem. Det kan fortfarande vara ett lönsamt val för scenarier när slutpunktsbeteendet ska testas med minimal overhead (vi använder den för att testa samtal till Amazons AWS-tjänster som S3).

Ange adaptrar

Adaptrar fungerar bra och främjar överläggning kring API-kontrakt och tydligt definierade kommunikationsgränser. Vi använder fortfarande detta tillvägagångssätt, särskilt när adaptern är mer komplex (som en JSON-RPC-uttag).

Så här ser en adapter ut:

Men för enkla HTTP-ändpunkter verkar adaptrar som mycket arbete och har en stor nackdel: De lämnar biblioteken som de förbrukar ur testekvationen. Om något i HTTP- eller JSON-bibliotek ändras, kommer testen inte att fånga det. Mängden produktionskritisk kod som lämnas otestad med detta tillvägagångssätt är oacceptabel.

Nutid och framtid

Bypass tillåter oss att starta en mycket enkel webbserver i test som simulerar externa tjänster vi använder.

Nu kan vi testa hela stapeln, inklusive HTTP-biblioteket, JSON-kodnings- / avkodningsbiblioteket och autentiseringsmekanismer. Bypass README är välskrivet, så jag kommer att spara detaljer om genomförandet. Vi ändrar dock lite hur vi använder det för att hålla testen konsekvent och läsbar:

För det första vill vi ibland kalla oss på Facebook när testerna körs som en fullständig integrationspaket. Vi gör detta oregelbundet för att säkerställa att Facebook API fortfarande fungerar enligt våra förväntningar. tillsats - inbegriper integration till blandningstest simulerar inte API men kallar istället för den externa tjänsten (rad 5, 7).

Vi är tydliga när vi simulerar förfrågningar till externa tjänster så att varje test som använder Bypass måste ha @tag facebook_bypass (rad 7).

Slutligen, den handle_fb funktionen (linjerna 30-39) kallas (givet att request_path tändstickor). Jag gillar att matcha i funktionshuvudet eftersom det tydliggör vilken väg vi reagerar på och låter oss definiera olika funktioner för olika vägar.

Så Bypass körs på endast test märkta med @tag: bypass och när vi inte kör vår integrationspaket. En sak vi gör när du konfigurerar Bypass låter taggen passera ett sid-id (linjer 8, 20). Så här är hur ett test som använder Bypass ser i all sin härlighet:

Som du kan se, är facebook_bypass taggen gör det tydligt att vi simulerar API: n (om inte vi är i integrationsläge). Det tillåter oss att skicka information till det simulerade API, och det är mycket enkelt att återanvända samma Bypass-konfiguration för olika test.

Jag hoppas det hjälper dig att testa externa API-er. Du hittar mig på Twitter (se nedan) om du har ytterligare frågor.