Automatisk test gør Happy Hyper-platformen fejlfri

Når det er muligt, baserer vi nye produkter på vores Happy Hyper-platform. Det er en stærk, lille, fejlfri kerne som gør vi får data- og applikationslag forærende og får en flyvende start samt et stabilt grundlag. Men hvordan sikrer vi at platformen forbliver fejlfri altimens den undergår løbende forbedringer og optimeringer? Den ene del af svaret er, at den er lille og simpel og det gør alting nemmere. Den anden del hedder automatisk test.

Hvorfor automatisk test?

I traditionel software-udvikling kunne en iteration f.eks. bestå af 4 ugers udvikling, efterfulgt af en testfase hvor man håber at finde alle de fejl man har indført. Det er en håbløs forældet fremgangsmåde som de fleste har forladt, så lad os i stedet tale om alternativerne.

Kanban, Continuous Delivery og hyper-agile begreber har sit indtog i udviklingsafdelinger verden over og betyder at der bliver udgivet oftere og hver udgivelse er mindre kompleks. Det nyder udviklerne og giver bedre software og hurtigere værdiskabelse. Men “forretningen” reagerer normalt ved bekymring om hvad det vil gøre for stabiliteten af produktet. Den bekymring er faktisk velbegrundet! Hvis man skal udgive flere gange dagligt og samtidig opretholde en høj kvalitet, så er der brug for automatisk test.

Hvis en komplet test af et produkt tager 3-5 dage og man ønsker at udgive 2 gange dagligt, så skal man ikke være matematikprofessor for at regne ud at det ikke kan lade sig gøre. En mulighed er at lave en fokuseret test som kun tager hånd om det som er ændret og det er ikke nogen dum idé, men for de fleste produkters vedkommende er det ikke muligt at overskue konsekvenserne af de ændringer man har lavet, så det giver øget risiko for ustabilitet. Fejlene vil typisk være mindre, fordi ændringerne er mindre, men forretningen bekymrer sig med god grund, for også små fejl bliver oplevet som ustabilitet af brugerne.

Automatisk test er løsningen. En automatisk test kan gennemføres hurtigere, så det er muligt at lave en komplet test ved hver udgivelse selvom der udgives ofte. Derudover er det en stor fordel, at den automatiske test ikke kræver at mennesker skal være tilgængelige og være optaget af at udføre testen, men at testen kan udføres automatisk af en server, når som helst og hele tiden uden nævneværdige omkostninger.

En almindelig fejl når man evaluerer udbyttet ved indførelse af automatisk test er, at beregne reduktionen af det tidsforbrug det kræver at udføre test. Det er korrekt at man får dette udbytte, men det er irrelevant. Det som gør automatisk test til en revolution er ikke det reducerede tidsforbrug, men det faktum at man kan udføre test hele tiden, hver dag, hver time og eller hver gang der skrives en ny kodelinje.

Forskellige typer automatisk test

Der er overordnet set tre typer automatisk test som er bredt anvendelige, almindelige og tilstrækkeligt udbredt til at der findes værktøjer der kan understøtte dem.

Browsertest

Denne type test er nem at forstå. I stedet for at et menneske klikker sig gennem et system, så opsætter man et manuskript og så udfører et framework (f.eks. Selenium) testen gennem en browser, præcis som et menneske ville gøre, men uden der behøver at sidde et menneske foran skærmen. Testen er god, for både brugergrænsefladen og logikken bliver testet på denne måde. Ulemperne er, at den er kompleks at sætte op, kræver meget vedligeholdelse, er til tider ustabil og tager lang tid at udføre.

Selvom det bare er en computer der gennemfører testen er det vigtigt den kan udføres hurtigt, for hvis det tager mange timer, sætter det begrænsninger for hvor ofte man kan udgive og hvor hurtigt man kan gentage en test der fejler. Derfor er browsertest sjældent det bedste valg.

Unit-test

Her skriver man kode som del af sin applikation som tester applikationens logik. Det kræver at applikationen er skrevet efter god praksis med Dependency Injection, men så er det også hurtigt og let for en udvikler at skrive utroligt detaljerede tests som dækker alle tænkelige og utænkelige scenarier.

Afhængigheder, såsom databaser og andre systemer, bliver “mocket” ud så de ikke komplicerer testen og forurener denne helt rene testtype. Dette er også et af problemerne med unit-tests, for man kan sagtens komme ud for at alle unit-tests lykkes, men applikationen fejler, fordi der er en fejl i en del af applikationen som ikke er dækket af unit-test.

Det er muligt, men sjældent praktisk muligt, at dække hele applikationen med unit-test.

Derfor risikerer unit-tests at blive en næsten akademisk øvelse som demonstrerer en fejlfri applikation i teorien, men ikke nødvendigvis i praksis. Unit-tests kan helt bestemt anbefales, men man skal bare forstå den indsats det kræver og de begrænsninger der trods alt er i denne ellers fremragende fremgangsmåde for test.

API-test

Hvis applikationen tilgås via et API, hvad der er tilfældet for Happy Hyper og de fleste andre moderne applikationer, er det muligt at udføre en API-test. Det gøres ved at opsætte API-kald som kan gentages igen og igen i forskellige variationer således at applikationen testes. I modsætning til unit-test, mocker man ikke afhængigheder ud, men lader faktisk applikationen tilgå databasen. Ved API-test bliver alle lag i applikationen derfor testet, bortset fra brugergrænsefladen.

For at testen kan gentages er man nødt til at starte med ingenting for hver test, da alternativet, at holde styr på data i en bestemt database, kræver for meget vedligeholdelse. I en SaaS-kontekst svarer det til at oprette en ny konto til hver test. Der er dem som mener at testen skal rydde op efter sig selv, men en test er beregnet til at fejle i ny og næ og så har man alligevel brug for en metode til at starte forfra. Derfor er det langt det bedste på langt sigt at have en API-test som starter med ingenting.

Hvad skal man vælge

Det er en god idé at kombinere de forskellige testtyper og anvende dem til det de er stærkest til. Ofte må man dog vælge hvor man lægger kræfterne og det er min erfaring at man får mest for anstrengelserne ved at fokusere på API-test. Det afhænger dog af applikationstypen, ikke mindst om forudsætningerne for en API-test er til stedet.

Sådan gjorde vi

Den opmærksomme læser har måske gættet at vi med Happy Hyper beror på API-test. Happy Hyper er fra starten lavet med henblik på at have et komplet API og det hjælper en hel del. Derfor er alle funktioner eksponeret i API’et. Vi har anvendt Postman til at opsætte API-tests som illustreret herunder.

Den første Collection “01 Auth” består af oprettelse af en konto og efterfølgende nogle simple og udetaljerede tests. Det sikres at hver konto er unik med et “Pre-request script”:

Der anvendes variabler gennem testen, som her “testNumber” der forhøjes med én for hver test, så det altid sker på en ny konto – og “accountName” som anvendes i alle øvrige tests til at sikre tests bliver gennemført på den nyoprettede konto.

For hvert API-kald testes en række ting; nogle gange blot at kaldet gik godt, men andre gange at specifikke værdier er til stede. Det gøres let med javascript, hvor der også kan anvendes Lodash.

Denne samme test kan udføres i forskellige miljøer. Udvikleren kan udføre den på sin egen maskine, en build-server kan udføre den på et testmiljø og en monitoreringsservice kan udføre den i produktion.

Når testen udføres gives et nemt overblik af de tests som er kørt og eventuelle fejl fremhæves. De kan derefter let gentages mens udvikleren åbner “debug” mode og finder frem til fejlen i sit lokale miljø. Da en konto altid oprettes fra ny ved hver test, er det garanteret at udvikleren kan genskabe fejlen i sit miljø.

Vedligeholdelse

Én ting er at opsætte API-tests, men hvad sker der når hverdagen sætter ind og skidtet skal vedligeholdes? Det kræver selvfølgelig disciplin men det er mindre tidskrævende end man skulle tro. Hele denne testsuite blev sat op på 4 arbejdsdage. Når nye funktioner udvikles, skal der selvfølgelig laves en tilsvarende API-test. Hvis det er et komplekst område kan det laves i en ny Collection og ellers kan det tilføjes en eksisterende.

Det er en god idé at sikre at hver Collection kan køres uafhængigt af de andre, så man hurtigt kan gentage sin test mens man skriver den. Så skal man skal kun køre opsætningen (i vores tilfælde, 01 Auth) og så den Collection man ønsker at teste.

Hvis der findes fejl som ikke er dækket af API-testen, kan fremgangsmåden vær, at fejlen først genskabes via API’et og dernæst rettes i bedste TDD-stil. Det tager 5 minutter at opsætte en test og det behøver ikke være en udvikler der gør det, men kan være en semi-teknisk kvalitetssikringsekspert.

Er Happy Hyper virkelig fejlfri?

Nej, selvfølgelig ikke – men jeg vil vove den bombastiske påstand at alle kernefunktioner virker nu og i al fremtid. Det er en stabil og kompakt kerne som man altid kan stole på fungerer.

Men selvfølgelig vil der altid være hjørnescenarier hvor man vil kunne finde fejl, specielt på nyudviklede funktioner, men ved hjælp af en komplet testsuite kan de hurtigt rettes og testen kan anvendes til at bekræfte at intet andet er ophørt med at fungere i mellemtiden. På den måde er API-testen og disciplinen til at vedligeholde den garant for et produkt med gradvist højere og højere kvalitet. Det tager tid at sætte op, men tiden er tjent hjem langt tidligere end man tror hvis det gøres rigtigt – og så giver det en bedre oplevelse for både brugere og udviklere.