Sådan testes eksterne API'er i Elixir med bypass

Vi prioriterer Service Oriented Architecture principper på Inverse. Det betyder, at vi har små, vedligeholdelige komponenter med klart definerede ansvarsområder. De kommunikerer med hinanden (for det meste), via repræsentative statsoverførsler eller REST, API'er.

Dette giver fleksibilitet og har tjent os godt med undtagelse af en betydelig facet: Testing. Ved test skal man undgå:

• Afhængighed af eksterne tjenester, der kører på samme maskine.
• Langsom test.

Fordi applikationer i sig selv er afhængige af eksterne tjenester, er det afgørende at have en teststrategi på plads for disse afhængigheder.

Vi har for nylig begyndt at bruge Bypass, og jeg vil forklare, hvordan vi ankom der og specifikt hvordan vi bruger det.

Fortiden

Mock metoder og returnere nogle eksempler data som dette:

Det var (og jeg tror stadig er) "vejen at gå" i Ruby / Rails verden. Desværre skaber dette en dårlig opførsel som bedst forklaret her af José Valim.

Vi begyndte at bruge ExVCR, som er et stort bibliotek, men har lignende ulemper som mocks / stubs: Det tilskynder dovenskab og fremmer ikke adskillelsen af ​​bekymringer, der er kritiske for veldefinerede API'er. ExVCR gør det muligt at "optage" og "afspille" live-live data. Det er meget nemt at integrere (herunder et par linjer i din test, og alt andet er taget hånd om). Men ideelt set skal du tænke på eksterne afhængigheder i prøver, ikke abstrakte dem ud. Det kan stadig være et levedygtigt valg for scenarier, når endepunktsadfærd skal testes med minimal overhead (vi bruger det til at teste opkald til Amazonas AWS Services som S3).

Indtast adaptere

Adaptere fungerer godt og fremmer overvejelser omkring API-kontrakter og klart definerede kommunikationsgrænser. Vi bruger stadig denne tilgang, især når adapteren er mere kompleks (som en JSON-RPC-stikkontakt).

Sådan ser en adapter ud:

Men for enkle HTTP-slutpunkter virker adaptrene som en masse arbejde og har en stor ulempe: De forlader bibliotekerne de forbruger ud af testligningen. Hvis noget i HTTP- eller JSON-bibliotekerne ændres, vil testene ikke fange det. Mængden af ​​produktionskritisk kode, der efterlades uprøvet ved denne fremgangsmåde, er uacceptabel.

Nutiden og fremtiden

Bypass giver os mulighed for at starte en meget simpel webserver i tests, der simulerer eksterne tjenester, vi bruger.

Nu kan vi teste hele stakken, herunder HTTP-biblioteket, JSON-kodnings- / dekodningsbiblioteket og autentificeringsmekanismer. Bypass README er velskrevet, så jeg vil spare detaljer om implementering. Vi ændrer dog lidt, hvordan vi bruger det for at holde testene konsekvente og læsbare:

Først og fremmest vil vi undertiden kalde op til Facebook, når testene køres som en komplet integration suite. Det gør vi uregelmæssigt for at sikre, at Facebook API stadig fungerer efter vores forventninger. Tilføjelse - omfatte integration til blandetest simulerer ikke API'en, men opfordrer i stedet til den eksterne tjeneste (linjer 5, 7).

Vi er eksplicitte, når vi simulerer anmodninger til eksterne tjenester, så hver test, der bruger Bypass, skal have @tag facebook_bypass (linje 7).

Endelig handle_fb funktion (linjerne 30-39) bliver kaldt (givet at request_path Tændstikker). Jeg kan lide at matche i funktionshovedet, da det gør eksplicit hvilken vej vi reagerer på og giver os mulighed for at definere forskellige funktioner til forskellige veje.

Så Bypass kører på kun tests mærket med @tag: bypass og når vi ikke kører vores integration suite. Endnu en ting, vi gør, mens du konfigurerer bypass, tillader, at mærket passerer et side id (linjer 8, 20). Så her er hvordan en test, der bruger Bypass ser i al sin herlighed:

Som du kan se, er facebook_bypass tag gør det eksplicit, at vi simulerer API'en (medmindre vi er i integrationstilstand). Det giver os mulighed for at videregive oplysninger til den simulerede API, og det er meget nemt at genbruge den samme Bypass-konfiguration til forskellige tests.

Jeg håber det hjælper dig med at teste eksterne API'er. Du kan finde mig på Twitter (se nedenfor), hvis du har yderligere spørgsmål.