Testdriven utveckling spar både tid och pengarTester är en mycket viktig del i utvecklingen av applikationer och programkomponenter. Utvecklingsmetoden testdriven utveckling, eller TDD (Test Driven Development) är en metod där man startar med att skriva ett eller flera testfall innan man börjar utveckla koden som testerna sedan ska köras på.
- Metoden kan kännas lite bakvänd för många, och ofta krävs det en hel del disciplin innan man lär sig utveckla på det här sättet. För som utvecklare vill man helst lösa problemet först och sedan testa om det fungerar. Med TDD är det precis tvärtom, säger Tommy Niittula på Nethouse i Borlänge.
Testerna stödjer funktionen
Först skapar utvecklaren ett antal testmetoder som givet ett antal parametrar ska ge ett visst resultat, till exempel att A och B ska ge svaret C. När testmetoderna är klara är det dags skriva själva funktionen som uppfyller detta krav. Med testernas hjälp har utvecklaren skapat ett stöd (som ett slags facit) i utvecklandet av funktionen. När testerna till slut ger rätt resultat kan vi förvissa oss om att vår funktion fungerar som det var tänkt.
Enhetstester
Testerna ska vara snabba och testa små enheter av koden, helst ända ner till funktions- och metodnivå. Testerna kallas enhetstester och följer ett speciellt mönster. Visual Studio 2005 Team Edition har inbyggt stöd för enhetstester men det finns även separata ramverk. Det mest spridda ramverket för enhetstestning är xUnit som bland annat finns för .NET (NUnit) och Java (JUnit).
För- och nackdelar
Det finns några uppenbara nackdelar med att utveckla testdrivet. För det första blir det mer kod att skriva eftersom det behövs skrivas kod för varje testfall. Och vid större förändringar av klasser och metoder kan även testfallen behöva ändras. I de fallen kan därför testdriven utveckling leda till att mer kod måste underhållas. Detta innebär att det tar lite längre tid att utveckla enligt TDD-principen.
- Samtidigt spar man tid eftersom att vi inte behöver rätta lika många buggar i slutet av projektet. Eller ännu värre, i förvaltningen när systemet redan är i drift. Kan vi fånga upp buggarna i ett tidigt skede skapar det lägre kostnader för buggrättningen, berättar Tommy.
Förhållningssättet är något som går under det engelska begreppet "fail fast", eller misslyckas tidigt och innebär att utvecklaren fångar upp och rättar felen direkt i samband med att man skriver koden. Fail fast är mycket enklare (och billigare) jämfört med att rätta buggar som dyker upp ett år efter driftsättning.
Tester driver fram designen
Ytterligare fördelar med att utveckla enligt TDD-principen är att det automatisk blir en testvänlig design av systemet.
- Om man gör modultesterna på traditionellt sätt, alltså i efterhand - finns det alltid en risk att designen är sådan att det helt enkelt inte går att testa alla delar på ett bra sätt, fortsätter Tommy.
Ersätter inte andra tester
Testdriven utveckling ersätter inte system-, integrations- eller acceptanstester. Dessa ska alltid ske innan leverans av ett system till en slutanvändare. Även om alla moduler och enheter fungerar felfritt var för sig enligt enhetstesterna är det ingen garanti för att de fungerar på rätt sätt tillsammans i en applikation. Enhetstester ger inga garantier för att applikationen ska fungera på det sätt som kunden förväntat sig. Styrkan med testdriven utveckling är istället att de små enheterna är så buggfria som möjligt, vilket gör att de flesta svårfunna felen i systemet är hittade och åtgärdade.
Att utveckla testdrivet är en förutsättning när utvecklingen går mot dynamiskt typade programmeringsspråk. Då kommer kompilatorn inte längre att hjälpa till att hitta fel på det sätt som vi är vana vid idag.
- Testdriven utveckling är något som är på stark frammarsch och de flesta stora utvecklargurus talar sig varma för metoden. Testa måste vi ju, och då kan vi väl lika gärna testa först, avslutar Tommy.
---------------------------------------------------------------------------------------------------------------
Nethouse har på uppdrag av Transportstyrelsen deltagit i utvecklingen av en "Risktäckande databas för trafikföreskrifter" RDT. En särskild webbplats har tagits fram, där trafikföreskrifter elektroniskt kan publiceras/kungöras av alla myndigheter som utfärdar trafikföreskrifter.
En del i utvecklingen av RDT har varit att utveckla delsystemet Beata där TDD använts i valda delar och framför allt i den komplicerade algoritm som är kärnan i systemet. På så vis har ett omfattande testbibliotek byggts upp från start och kommer vara ett viktigt stöd vid förvaltningen av systemet.
Genom användning av Beata blir det möjligt att vidarebearbeta information från trafikföreskrifter till trafikregler i digital form så att de kan användas i IT-stödda trafiksystem.
