Hvorfor driver ikke utviklere med TDD?
Da jeg tok en bachelor i informatikk på Høgskolen i Østfold og senere en Master i informatikk på Universitet i Oslo, lærte vi ikke om TDD, BDD eller andre former for testing. Jeg husker jeg ikke hadde kjennskap til begrepet testing selv heller, og det ble i alle fall ikke nevnt i noen av kursene jeg tok. Systemutvikling var derimot et velkjent begrep gjennom studietiden, men det jeg foretok av testing kan i beste fall kalles manuell testing. Gjennom å jobbe med rekruttering opp igjennom har jeg kjørt en del tekniske intervjuer, og det er ikke lenger noen som ikke kjenner til begrepene TDD, BDD og andre varianter og i alle fall kan forklare hva de går ut på generelt sett. Det tenker jeg vitner om en utvikling i bransjen, men også på de ulike skolene hvor testing nå er en del av pensum.
Og bare for å oppsummere noen av fordelene med TDD:
- Det tillater utviklerne å skrive mindre deler med kode siden man initielt bare skal skrive en feilende test.
- Du får en mer fleksibel kode siden koden blir utviklet i mindre og uavhengige deler.
- Det genererer raskere feedback, for eksempel ved at din siste endring eller refaktorering ødela tidligere fungerende kode.
- Mer trygghet hos utviklerne.
Men om nå alle kan det og alle kjenner fordelene, da dukker spørsmålet mitt opp:
Hvorfor driver ikke utviklere med TDD?
Etter min karriere med over 15 år som IT-konsulent som systemutvikler og teamleder, diskusjoner med kollegaer og ikke minst nå sist på JavaZone, så har jeg kommet fram til tre ulike mulige problemer og to mulige løsninger.
For å ta problemene først:
Tid
Tid er alltid en faktor på prosjekt, spesielt som konsulent i oppdrag hos kunden. Prosjektene har budsjetter som skal innfris, scope er gjerne stort, og det er ofte harde tidsfrister som skal holdes. Når utviklerne skal sette i gang med nye features og brukerhistorier, og tiden er knapp, så må det gå på bekostning av noe. Utviklerne legger ofte æren sin i å utvikle kvalitet — så hva ender opp med å vike? Testing og TDD er i alle fall lavt ned på prioriteringslisten når ting skal leveres.
TDD går som kjent ut på at du først skriver en feilende test, så lager du funksjonaliteten for at testen ikke feiler, refaktorerer og slik går syklusen videre. Min antakelse er at når tiden er knapp så skriver utviklerne i beste fall tester på slutten, når all kode er ferdig skrevet og alle kravene er dekket.
Kunnskap
For meg symboliserer biblioteket kunnskap (eller i alle fall muligheten for uendelig med kunnskap for den som har tid, lyst og anledning). Universitetsbiblioteket på Blindern var for meg en inspirasjonskilde under mitt arbeid med masteroppgaven. Min erfaring er at mangel på kunnskap gjør livet som utvikler mer tidkrevende og komplisert. Mange her har nok jobbet med monolitter og legacy-systemer hvor du skal inn og gjøre små endringer, men siden du har mangel på kunnskap om hvordan alt fungerer så kan selv en liten endring ta over en uke å få implementert.
Som fersk i gamet og rett fra skolen hadde jeg ikke tastatur-snarveiene i fingerspissene da jeg satt og utviklet i Eclipse. Men det gjorde det derimot hos makkeren min som på 1–2–3 hadde lagt til nye klasser, pakker og testklasser. Mangel på kunnskapen gjorde meg mindre effektiv.
Det samme gjelder TDD. Mangel på kunnskap om hvorfor og hvordan du best mulig gjør det. Om du ikke kan det selv, så må noen med kunnskapen (typisk en mer erfaren kollega) ta seg tid til å jobbe sammen om det.
Metodikk
Det finnes mange ulike utviklingsmetodikker som eksempelvis Feature driven development, devops, vannfall, xtreme programming osv. Hos noen kunder jeg har vært hos så er det gjerne laget egne varianter av utviklingsmetodikk. Skatteetaten har for eksempel sin FSUM som står for Felles SystemUtviklingsMetode. FSUM er basert på prinsippene i det smidige manifestet og er bygget rundt en gjennomføringsmodell som blant annet involverer en MVP-tankegang. Som alt annet her i livet har det sine fordeler og ulemper.
Det jeg kjenner litt på da er om utviklingsmetodikken blir en slags tvangstrøye i prosjektene. Ingen folk er like, ingen prosjekter er like og dermed har man ulike behov. Og det ideelle slik jeg ser det, er å ha en meny av muligheter å velge mellom slik at man kombinere litt og mikse slik man vil.
Men hva dette med TDD å gjøre? Jo! Poenget mitt er at om ikke TDD er en del av kunden sin metodikk så er det også mindre sannsynlighet for at det blir gjort. At TDD ikke er en del av kundens metodikk kan skyldes ulike årsaker (de to tidligere nevnte faktorene om tid og kunnskap kan også spille inn her). Men samtidig, om TDD hadde vært en del av metodikken så tenker jeg det er viktig at det ikke blir slik at man alltid MÅ gjøre det. Dette blir en lengre diskusjon som jeg ikke skal gå i detalj på her, men det er ikke alle typer oppgaver som egner seg for TDD etter min mening.
Men nok problemer, nå er det over til et par mulige løsninger:
Parprogrammering
På mitt første prosjekt hos Tine BA satt jeg sammen med en kollega hvor vi programmerte sammen i god TDD-stil: med feilende test, skrev funksjonalitet slik at testet kjørte grønt, refaktorerte og så videre. Jeg fikk det inn i fingrene. Ja, det krevde tid og energi å sette seg inn i, men da jeg som relativt fersk satt alene på prosjektet 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. Hadde det ikke vært for at kollegaen min tok seg tid til å lære meg opp i TDD og at vi jobbet sammen, så hadde TDD vært mer som et buzzord for min del. 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.
Kultur
Jeg tenker at om du har et team hvor du ønsker at utviklerne skal jobbe med TDD må det bygges en kultur for det, på lik måte som man bygger en kultur for å ha en lav terskel for å hjelpe hverandre i teamet eller en kultur for å alltid si hei når du kommer på kontoret om morgenen.
For å få til å bygge kultur så liker jeg at noen er kulturbærere, altså at en i teamet tar på seg ansvaret med “å 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. På den tiden var det ingen i teamet mitt som drev med TDD, men gjennom intervjuene for å få nye team-medlemmer hadde jeg ofte spørsmål om testing og TDD. På et tidspunkt var jeg på jakt etter en tech-lead som kunne ta hovedansvaret for den mer tekniske biten i teamet i og med at jeg hadde fått en del andre oppgaver som teamleder. 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. Jeg brukte rett og slett han som en kulturbærer, og med stort engasjement og pågangsmot ble TDD en større del av prosjektet.
For å kort oppsummere så mener jeg tid, kunnskap og metodikk er tre av årsakene til at utviklere ikke driver med TDD, men det er likevel håp. Om du tar i bruk parprogrammering og jobber med kulturen i teamet, er det fremdeles muligheter for at du kan få det til fordi fordelene med TDD er mange og kjente.
