Fördelar med testdriven utveckling: viktig statistik och studier
I den här artikeln går jag igenom en del statistik och studier om testdriven utveckling för att förstå hur den har använts, vilka fördelarna är och vilka utmaningar team står inför med detta arbetssätt.
Traditionellt sett fortskrider programvaruutvecklingsprocessen linjärt. Under de senaste decennierna har dock programvaruutvecklingen, i takt med att agila system blivit allt populärare (så många som 87% av teamen följer ett agilt eller agiliknande arbetssätt), börjat använda olika metoder som tar hänsyn till projektets krav och karaktär.
Tekniken testdriven utveckling (TDD) är en av de metoder som har väckt uppmärksamhet inom området för agil programvaruutveckling.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
I en forskningsartikel som publicerats av Institute of Electrical and Electronics Engineers säger författarna Yahya Rafique och Vojislav Misic att ”Testdriven utveckling (TDD) är en av hörnstenarna i utvecklingsprocessen Extreme Programming (XP)” (Källa).
Mannen som sägs ha utvecklat TDD uppges ha ”uttalade 2003 att TDD uppmuntrar till enkla designer och inger förtroende” (Källa). Frågor kvarstår dock kring de påståenden om produktivitet och kvalitet som har gjorts om TDD.
Vi tog oss tid att samla in den senaste statistiken om TDD för att pröva de påståenden som har gjorts.
Den här artikeln börjar med att definiera TDD-konceptet och hur det skiljer sig från det traditionella arbetssättet. Därefter tittar vi på en del statistik som antingen bekräftar eller avfärdar påståendena om TDD.
Vad är testdriven utveckling?
Testdriven utveckling är ett arbetssätt där ett test skrivs innan programutvecklaren skapar produktionskoden som ska uppfylla testet. Grundidén med denna teknik är att låta kodförfattaren ta sig tid att överväga sin design eller sina krav innan funktionell kod skrivs.
TDD-processen
- Skriva testet: I TDD börjar alla nya funktioner med att ett test skrivs. Programmeraren måste förstå specifikationen och kraven för funktionen. För att uppnå detta behöver de gå igenom användarberättelser och användningsfall för att förstå syftet med den nya kod de utvecklar.
- Testet misslyckas: När programmeraren har skrivit testet kör de det. Eftersom det ännu inte finns någon kod som implementerar det kommer testet att misslyckas. Detta bekräftar att det automatiserade testramverket fungerar korrekt och utesluter möjligheten att det nya testet alltid kommer att godkännas eftersom det är felaktigt.
- Skriva koden: Nu vet programmeraren att funktionen fungerar enligt designen. De skriver nu koden som får testet att godkännas. Koden behöver inte vara perfekt eller klara testet på ett utmärkt sätt, men det spelar ingen roll. Utvecklaren förväntas inte skriva kod utöver den funktionalitet som testet skapades för att kontrollera.
- Köra testerna: När programmeraren vet att funktionen fungerar enligt designen kan hen, varje gång ny kod släpps, använda ett testhanteringsverktyg för att köra testet igen. Det ger en bekräftelse på att den senaste uppdateringen inte har förstört den tidigare funktionen.
- Refaktorera koden: I TDD måste kodbasen kontinuerligt rensas upp i takt med att den växer. Eftersom programmerarens huvudsakliga fokus i de ovanstående stegen endast var att skriva koden säkerställer detta steg effektiviteten. Det gör det möjligt att förbättra den interna strukturen i programmets källkod samtidigt som dess externa egenskaper bevaras. Detta steg kan ta bort dupliceringar och lägga till ny funktionalitet.
- Upprepa: Ovanstående steg upprepas automatiskt för att säkerställa att TDD-cyklerna omfattar alla funktioner.
Skillnader mellan TDD och traditionell utveckling
För att förstå TDD verkar det lämpligt att fastställa hur metoden skiljer sig från de traditionella metoderna för programmering.
Den största skillnaden är att de traditionella metoderna följer en linjär process, medan TDD genomgår en cyklisk process.
Programmerare som använder traditionella testmetoder börjar med att skapa koden och fokuserar först på testet i slutet av utvecklingsprocessen. Den som följer TDD-modellen börjar däremot med att skapa testet och utvecklar sedan koden som klarar testet. Detta tillvägagångssätt delar många principer med vänsterförflyttningen inom programvarutestning.
Medan programmeraren som använder det traditionella tillvägagångssättet kan fokusera på kodens korrekthet, löper hen risken att inte upptäcka alla fel i koden. Programmeraren som använder TDD-metoden arbetar med koden tills den klarar testet genom att omstrukturera koden. Detta görs tills koden uppfyller funktionaliteten, en process som sannolikt leder till färre buggar.
Är TDD långsammare eller snabbare än traditionell testutveckling?
När det gäller frågan om TDD gör programmeringsprocessen snabbare finns det motstridiga uppgifter från olika källor.
En fallstudie som omfattade programvaruingenjörsteam från Microsoft och IBM kom fram till att ”teamen upplevde en ökning av den initiala utvecklingstiden på 15–35 %” när de använde TDD-tekniken. Studien påpekar dock att detta är siffror som ”uppskattats subjektivt av ledningen” (Källa).
Om man ser det ur perspektivet att Microsofts och IBMs studier visar att kvaliteten förbättrades, kan man hävda att TDD på lång sikt sparar den tid som annars hade behövts för att åtgärda problem. Teamen på Microsoft och IBM höll med om detta (Källa).
En studie som fokuserade på erfarna yrkesverksammas första uppfattningar när de använde TDD drar slutsatsen att ”efter att ha övervunnit de inledande svårigheterna med att förstå var man ska börja och hur man skapar ett test för en funktion som ännu inte finns, får deltagarna större förtroende för att implementera nya funktioner och göra ändringar tack vare den breda testtäckningen” (Källa). Detta verkar tyda på att saker och ting förbättras med tiden.
I en text för den digitala publiceringsplattformen Medium.com fokuserar programmeraren och författaren till ”Att komponera programvara” och ”Programmering av JavaScript-applikationer”, Erick Elliot på hur TDD förändrade hans liv. Elliot håller med om att processen kan vara långsam i början, men säger: ”någonstans efter ungefär två år började något magiskt hända: jag började koda snabbare med enhetstester än jag någonsin hade gjort utan dem” (Källa).
Det verkar som att TDD kan göra saker långsammare inledningsvis. Om man däremot ser det ur ett långsiktigt perspektiv kan den tid som sparas genom kod av bättre kvalitet kompensera för den tid som går förlorad i början. Det kan också förväntas att programmerare sannolikt arbetar snabbare när de blir bättre på TDD.
Det finns också många andra faktorer att ta hänsyn till när man försöker mäta hur lång tid det tar att uppnå ett resultat av hög kvalitet. För mer information kan du lyssna på Niall Lynchs avsnitt i podden The QA Lead om att mäta T2Q (tid till kvalitet).
Leder TDD till färre buggar?
I diskussionen ovan framställs en av TDD:s främsta fördelar vara att det leder till färre buggar. Men håller statistiken med?
Samma studier av ingenjörsteamen på Microsoft och IBM som nämndes ovan kom fram till att ”defekttätheten före lansering för de fyra produkterna minskade med mellan 40 och 90 % jämfört med liknande projekt som inte använde TDD-metoden.” Mer specifikt rapporterade IBM-teamen en minskning av defekttätheten med 40 %, medan teamen på Microsoft rapporterade en minskning på 60–90 % (Källa).
Stödjer statistik om testdriven utveckling slutsatsen att TDD ger bättre kvalitet?
Med utgångspunkt i resultaten från en studie som presenterades vid det första internationella IEEE-symposiet 2007 i Finland rapporterar Maria Siniaalto och Pekka Abrahamsson att TDD har visat sig ge bättre kodkvalitet jämfört med programvara som utvecklats utan TDD (Källa).
I sin artikel hänvisar Siniaalto och Abrahamsson till en studie som genomfördes i Kina och som kom fram till att TDD förbättrade processuppföljning och uppgiftsskattning. Samma studie drar slutsatsen att ”TDD också förbättrar efterlevnaden av konsekventa metoder och riktlinjer.” Detta leder till bättre kvalitet med färre defekter. Dessutom kunde de team som använde TDD åtgärda sina defekter snabbare (Källa).
En studie som genomfördes bland utvecklare med omkring tio års yrkeserfarenhet i genomsnitt, för att undersöka deras uppfattningar när de använde TDD, citerar en utvecklare som säger: ”TDD har hjälpt mig att förbättra koden och göra den mer läsbar.” En annan deltagare uppger att ”TDD ger bättre underhållbarhet” (Källa).
Främjar TDD enklare design?
Boby George och Laurie Williams, som båda arbetade vid institutionen för datavetenskap vid North Carolina State University, genomförde ett experiment där 24 programmerare delades in i två grupper: den ena använde TDD och den andra den linjära metoden.
George och Williams rapporterar att av deltagarna ansåg ”92 % av utvecklarna att TDD leder till kod av högre kvalitet, 79 % ansåg att TDD främjar enklare design och 71 % ansåg att metoden var märkbart effektiv” (Källa).
Denna statistik om testdriven utveckling och kvalitet ger en stark indikation på att TDD faktiskt leder till kod av högre kvalitet och enklare design.
I en artikel som publicerats av den kostnadsfria utbildningsportalen Guru99.com säger Kanchan Kulkarni: ”TDD gör koden enklare och tydligare. Det gör att utvecklaren behöver underhålla mindre dokumentation” (Källa).
Är det enkelt att införa TDD-design?
Av George och Williams experiment framgår att 56 % av de professionella utvecklarna ansåg att det var svårt att komma in i ett TDD-tankesätt, medan 23 % menade att avsaknaden av en inledande designfas var orsaken till denna svårighet. Av samtliga svarande ansåg 40 % att det är svårt att införa TDD (Källa).
Denna statistik om testdriven utveckling och införande visar att TDD uppfattas som svårt att införa.
Är TDD överskattat?
I en artikel som publicerats på Medium.com använder Tylor Borgeson, som beskriver sig själv som en fullstack-utvecklare med intresse för maskininlärning, AI, infrastruktur, DevOps och agila metoder, rubriken ”Testdriven utveckling är överskattad.” Att han har placerat rubriken inom citattecken visar dock att detta inte är ett påstående han själv gör.
Borgeson tar sedan upp dem som säger att metoden är överskattad och långsam och berättar för dem att de flesta som har denna uppfattning inte har använt metoden tillräckligt länge. I slutet av artikeln säger han: ”Öva nu på testdriven utveckling tills det inte längre gör ont” (Källa).
Vad händer härnäst?
Lär dig metoder för kvalitetssäkring av experter i podden The QA Lead
Anmäl dig till nyhetsbrevet från The QA Lead för att få våra senaste guider och poddavsnitt
Ställ dig i kö till The QA Leads onlineforum för intressegemenskap där du kan dela bästa praxis med andra yrkesverksamma inom kvalitetssäkring och programvarutestning.
Hoppas vi ses där!
