De siste årene har Simen (27) flere commits enn noen andre til braksuksessen Jest.js

OSLO SENTRUM (digi.no): – Jeg vil anbefale det for alle. Selv til små hobbyprosjekter. Jeg tviler på at det finnes noen som lager noe på web som ikke hadde hatt nytte av Jest, forklarer utvikleren Simen Bekkhus.

Fra lokalene i Møllergata jobber han til daglig som utvikler for oppstartsselskapet Folio. Sammen med et knippe andre lager han en kombinert regnskaps- og nettbankløsning for bedrifter ved hjelp av Typescript, React og GraphQL.

Men noen timer i uken sniker han seg unna for å jobbe med noe helt annet: Megapopulære Jest.js.

De siste to årene har nordmannen over 200 commits til testrammeverket, som først ble utviklet hos Facebook. Det betyr at han har bidratt med kode flere ganger enn noen andre til i dette tidsrommet.

Når får man bruk for Jest?

Se for deg at du sitter alene på digi.no-kontoret, og har nettopp fått beskjed om en kritisk bug på våre nydelige nettsider.

Du finner feilen, retter den, pusher, stålsetter deg – trekker pusten dypt – og ruller ut.

Nervøst åpner du «digi.no» for å se resultatet. Til din store forskrekkelse oppdager du at hele siden er nede.

Det viser seg at du har glemt å gjøre om tallene dine til strenger før du passet dem til fiksDigiBug()-funksjonen. Du fikser feilen, men til journalistenes irritasjon har forsiden allerede vært nede i fem minutter.

Alle ser stygt på deg, og du kjenner skammen bre seg utover kroppen. Søren klype, altså.

Vokser raskt

Det er i slike situasjoner Jest.js kan komme til nytte. Jest er et rammeverk som lar deg skrive en rekke tester for koden din, hvor du spesifiserer hva du forventer at den skal gjøre.

Når du har laget testene, kjører du disse når du gjør en endring i koden. Du får opp en rekke med rød eller grønn tekst som sier om du klarte deg gjennom testene, eller om noe feilet.

Å skrive en grunnleggende test er forholdsvis enkelt. Alt man gjør er å kalle funksjonen test(), for så å legge inn hva man tester – expect(sum(1, 2)) –, og hva man forventer at dette skal bli – toBe(3).

Dersom man har skrevet gode nok tester, kan man senke skuldrene og pulsen, og forhåpentligvis redusere antall paniske quickfixer som oppstår like etter en utrulling.

Jest er riktignok ikke det eneste rammeverket som gjør dette for Javascript. Mocha og Jasmine er andre testrammeverk som er omtrent like populære. I tillegg har man blant annet Ava, som norske Sindre Sorhus står bak.

Men Jest er det som vokser desidert raskest. I den verdensomspennende State of JS-undersøkelsen var det bare 4,7 prosent av de spurte som benyttet rammeverket i 2016. I 2018 var tallet 39,6, og hele 29,7 prosent meldte at de var interessert i å lære det. Også i Norge begynner rammeverket å bli svært populært.

– Jeg var og pratet på React Meetup her i Oslo i høst. Der spurte jeg hvor mange som hadde brukt Jest, og av cirka 100 mennesker rakk nesten alle opp hånden, forklarer han.

Og populariteten har flere klare årsaker, mener 27-åringen:

– Noe av det beste med Jest er at det er veldig utviklervennlig. Alt er klart utav boksen: Testdekning, mocking og transformering (av som som ikke er vanilla Javascript, journ. anm), forklarer Bekkhus.

Jest fungerer også på kode som kompilerer til Javascript, som Typescript og React. Faktisk installeres Jest automatisk når du lager en ny React-app ved hjelp av kommandoen create-react-app.

– Du kan skrive enhetstester, integrasjonstester og ende- til endetester – alle slags tester du har lyst til å skrive, forklarer Bekkhus.

(Artikkelen fortsetter under bildet).

– Må ikke være 100%

– Tar det ikke lang tid å kode dersom man skal skrive tester for alt?

– Selv bruker jeg kanskje en tredjedel av tiden jeg bruker på å skrive kode, til å skrive tester. Men så er det en ganske liten del av utviklingstiden som går til å skrive faktisk kode, påpeker han.

Flere snakker i dag om testdreven utvikling (TDD) – altså at man skriver testene før man skriver selve koden. Bekkhus er tilhenger av konseptet, men mener det er begrenset når man kan bruke det – bedriften han jobber i, Folio, benytter for eksempel ikke testdrevet utvikling.

– TDD er jo veldig skoleriktig. Og hvis du vet nøyaktig hva du skal lage, fungerer det veldig bra. Da kan du skrive testene som «user stories».

– Men med et nytt produkt vet man ikke alltid hva man skal lage, blir det ikke like enkelt.

Man trenger heller ikke 100 prosent testdekning – altså at man treffer hvert eneste uttrykk i koden, ifølge Bekkhus.

– Man sikter seg kanskje heller inn på 80-90 prosent, da det alltid vil være edge caser som endrer seg, og ikke er verdt å skrive tester for, forklarer han.