- Når utviklerne skal sette i gang med nye features og brukerhistorier, og det er knapphet på tid, så må det gå på bekostning av noe, sier Anders Hefre, avdelingsleder for utvikling og arkitektur i Systek, til kode24.
Denne uka holder Hefre foredraget "Hvorfor driver ikke utviklere med tdd?" på testkonferansen ODIN 2022.
Til kode24 sier Hefre at utviklere ofte legger ned æren sin i å utvikle kvalitet. Dette gjør at testing og TDD faller lavt ned på prioritetsskalaen når ting skal leveres.
Det mener han er feil.
- Tester er minst like viktig, om ikke viktigere, enn resten av koden
TDD dekker alle kravene til kunden
TDD står for test-drevet utvikling, og er en teknikk som benyttes for skrive testkode før produksjonskode gjennom korte iterasjoner.
Ifølge Hefre består en iterasjon gjerne av at man først skriver en feilende test, deretter implementerer man funksjonaliteten i produksjonskoden slik at testen passerer.
- Til slutt refaktorerer man koden slik at den blir bedre, i form av for eksempel lesbarhet. Deretter gjør man en ny iterasjon. Til slutt har man dekket alle kravene i den nye funksjonaliteten som kunden ønsket seg, sier han.
Hefre sier det er flere gode argumenter for å gjøre TDD.
- Som utvikler er det større trygghet i å gjøre endringer i eksisterende kode om man benytter seg av TDD. Man opplever gjerne færre feil og får raskere feedback, for eksempel ved at den siste kodeendringen eller refaktoreringen ødela tidligere fungerende kode.
Han sier at utviklerne også vil oppleve bedre fokus, samt at man får mer fleksibel kode gjennom at man utvikler mindre deler av systemet.
«Som utvikler er det større trygghet i å gjøre endringer i eksisterende kode om man benytter seg av TDD.»
Testutvikler hos NRK forklarer jobben: - Veldig kjedelig å skrive tester
Tre problemer står i veien for TDD
Ifølge Hefre er det tre problemer som gjør at utviklere ikke bruker tiden på TDD: Tid, kunnskap og metodikk.
- Tid er alltid en faktor på prosjekt og i oppdrag man sitter i hos kundene våre, spesielt som konsulent. Prosjektene har budsjetter som skal innfris, scope er gjerne stort, og det kan fort være knapt med tid.
Han legger til at knapphet på tid gjør at utviklere i beste fall tester på slutten, når all kode er ferdig skrevet og alle kravene er dekket. Mangel på kunnskap om TDD kan gjøre arbeidshverdagen tyngre.
- Om man ikke kan det selv, så må noen med kunnskapen, typisk en mer erfaren kollega, ta seg tid til å jobbe sammen om det.
Hefre viser til at det finnes mange utviklingsmetodikker.
- Men er ikke TDD ikke en del av kundens metodikk, er det mindre sannsynlig for at det blir gjort.
«Som fersk konsulent har man gjerne litt mindre krav på seg til å levere så mye den første tiden.»
Begynn med parprogrammering
Hefre har to forslag til hvordan du kommer i gang med TDD i ditt prosjekt: Kultur og parprogrammering.
- På mitt første prosjekt hos Tine satt jeg sammen med en kollega hvor vi programmerte sammen i god TDD-stil med feilende test, skrive funksjonalitet slik at testet kjørte grønt, refaktorere, og så videre. Jeg fikk det inn i fingrene.
Han legger til at det krevde tid og energi å sette seg inn i.
- Men da jeg som relativt fersk satt alene på prosjektet i en periode, fordi kollegaen min hjalp til på et annet prosjekt, så kjente jeg tryggheten i å kjøre TDD og ha tester som kontinuerlig kjørte grønt og med funksjonalitet som dekket kundens behov.
Hefre sier at hadde det ikke vært for at kollegaen tok seg tid til å lære ham opp i TDD, hadde det nok vært mer som et buzzord for han.
- Som fersk konsulent har man gjerne litt mindre krav på seg til å levere så mye den første tiden. Dette kombinert med min kollegas erfaring løste to av de tidligere nevnte problemene med tid og kunnskap.
Testleder: - Foreslår at vi begynner å presentere oss som kvalitetspådrivere!
Du må bygge en kultur
Dersom du har et team hvor du ønsker at utviklerne skal jobbe med TDD, mener Hefre at det må bygges en kultur for testing.
- For å få til å bygge kultur, så liker jeg at noen er kulturbærere, altså at en i teamet tar på seg ansvaret for å dra lasset. I et oppdrag hos en kunde var jeg teamleder og fikk ansvaret og gleden av å bygge opp et team, og hadde stor påvirkningskraft og innflytelse på hvem som kom inn i teamet, sier han.
På den tiden var det ingen i teamet som drev med TDD, men via intervjuene for å få nye teammedlemmer hadde Hefre ofte spørsmål om testing og TDD.
- Jeg intervjuet en person som hadde veldig fornuftige tanker rundt TDD og virket engasjert, så jeg tenkte at det kunne bli en fin måte å få innført TDD på i større grad i prosjektet, sier Hefre.
- Jeg brukte rett og slett han som en kulturbærer, og med stort engasjement og pågangsmot så ble TDD en større del av prosjektet.
