Många pratar om hur bra det är, men är det egentligen någon som har "hard facts" som bevisar att testdriven utveckling verkligen är bra? Om det är bra, är det bara gröna skogar eller finns det några avigsidor också?
Det har gjorts studier om detta men tyvärr har de ofta varit exprimentella studier där man involverar studenter i olika kodningsexpriment. Det har av det skälet funnits flera invändningar som har kunna gjort inför resultaten av dessa studier.
Nachiappan Nagappan, ifrån Microsoft Research, har istället gjort en studie på riktiga utvecklingsprojekt, tre inom Microosft och ett inom IBM. Han har också gjort det i efterhand så att utvecklingsprojektens deltagare inte visste, medans de skrev koden, att de skulle vara med i någon undersökning. Och till slut har han också jämfört med likvärdiga och riktiga utvecklingsprojekt för att se vilka skillnader som det blev när man använder TDD.
Resultaten är spännande
- Antal buggar i systemen minskade mellan 40% och 90%
- Det tog 15% till 35% längre tid att utveckla
Vill man alltså hitta fler buggar direkt i utvecklingsfasen och inte i någon specifik testningsfas eller i produktion så är testdriven utveckling en metod som man skall ta till sig.
Läs hela rapporten här och se en webcast här.
Nu är det väl inte riktigt så enkelt? Du måste ju väga den totala tiden för utveckling och bugrättning mot varandra. Rapporten nämner väl även att antalet buggar i rapporten är både sådant hittat vid funktionstest och efter release. Så bugrättningstiden efter release verkarinte vara inräknad, eller? Och när man jämför utvecklingstiderna, hade referensprojektet lika mycket enhetstester utan TDD som med TDD. Jag tvivlar starkt.
Sedan talar man om att detta va teamens första pojekt med TDD. TDD tar IMHO mycket längre tid i början än när man börjar bli bra på det. 15% låter ärligt talat lågt i mina öron, för att vara det första TDD projektet för teamet.
Så det finns många viktiga aspekter förutom "hitta buggarna tidigt eller sent" som jag tycker motiverar ett bifall för att TDD (och alla dess släktingar BDD, EDD, etc) funkar (när det utförs korrekt av motiverade utvecklare).
Posted by: Cellfish | 2008-12-19 at 14.15
Sen måste man väga in hela applikationens livslängd, TDD leder till bättre design som är lättare att underhålla och vidareutveckla.
Nya funktioner och bugfixar kan snabbare produktionsättas då manuella regresionstester ej behövs eller blir lika omfattande.
Enhetstester funkar som en sorts dokumentation som underlättar för nya utvecklar som ska sätta sig in ett befintligt system.
etc, etc. :)
Posted by: Torkel Ödegaard | 2008-12-20 at 02.02
Intressant undersökning - trots de kommentarer, som i mycket säger det jag känner också spontant.
Posted by: Olof Bjarnason | 2008-12-20 at 11.58
Jag håller med er i mångt och mycket. Men just genom att detta är komplext och det finns många faktorer så har det varit svårt att göra bra undersökningar. Denna tycker jag verkar ta en bra ansats, sedan finns det många andra faktorer som man skall ta i anspråk.
Det som jag tycker är lite synd är att när jag är ute och pratar med företag är det väldigt sällan som man använder TDD överhuvudtaget. En av mina frågor är hur vi skall få folk att prova på för att se om det fungerar i deras miljö. Men TDD är svårare att börja med än vad man tror.
Tack för feedbacken.
/dag
Posted by: Dag | 2008-12-22 at 07.24
Dag: ett sätt tror jag är att få folk att pröva på sin fritid istället för på jobbet.
Jobbet = stress, press => inte kreativ eller pedagogisk miljö. Grupptryck från kollegor att inte skilja sig från mängden etc. massa psykologiska effekter som får den enskilda att sälla sig till gruppen istället för att pröva nya vägar.
Jag är med på en TDD-mailinglista (testdrivendevelopment på yahoo groups). Då vi bollade lite av de idéer du också har, angående svårigheten att komma igång på jobbet, satte vi ihop en lista med TDD-problem som är lämpliga för att komma igång. Det är i alla fall tanken. Besök gärna och sprid vidare, alltihop är public domain så det går bra att använda om du vill på kurser om du är ute hos företag:
http://sites.google.com/site/tddproblems/
Posted by: Olof Bjarnason | 2008-12-23 at 00.53
Att öva på fritiden är nog tyvärr bara något som fungerar för de som verkligen brinner för utveckling och jag tror faktiskt inte att det är de personerna som är de som är svårast att övertyga. Min personliga erfarenhet är dock att den stora massan fnyser åt oss som håller på med det här på fritiden för att "vi inte har familj och liv" (vilket självklart är en felaktig iaktagelse). Kan man inte åstadkomma det på jobbet kommer man inte kunna "få med sig alla".
Som du skriver olof är det många somkänner stress på jobbet så de "hinner inte börja med TDD" för nästa dead-line ligger för nära. En verklighet många av oss befunnit (eller befinner) oss i. Men som med så många andra förbättringar så är de allra flesta omöjliga att genomföra i längden om inte "management" är med på tåget. Problemet är således flerhövdat. Men...
De allra flesta brukar kunna gå med på att med TDD tar det längre tid att komma fram till en release, men att efter releasen så är antalet defekter avsevärt lägre. Beslutet att prioritera kvalité framför mängden features till ett visst datum måste fattas av management/produktägaren/beställaren och här kommer statistik som i den nämnda rapporten in i bilden. Vägrar man fatta detta beslut om kvalité är man i mina ögon i princip dödsdömd från början.
När väl beslutet om kvalité fattats så måste alla utvecklare övertygas. Många kommer ha svårt med TDD i början eftersom det tar mycket längre tid i början. Och innan man verkligen sett fördelarna med egna ögon ("shit den där buggen hade varit svår att hitta senare" eller "vilken bra design av klassen det blev - så som TDD fick mig att skriva klassen hade jag aldrig tänkt på annars") så handlar det om ren viljestyrka. Till detta kommer den dåliga klangen av "test" i TDD. Personligen pratar jag i första hand om BDD eller EDD hellre än TDD. Så psykologi är viktigt... Sannolikt behövs även en TDD coach till hands för att ett team som börjar med TDD skall undvika de värsta misstagen och tappa sugen bara därför...
Jag tror inte det finns en "silver bullet" till hur man får fler att arbeta med TDD (et al); man måste jobba brett och vara lyhörd till organisationens behov och inställning. Men första stegen är nog under alla omständigheter att tala om kvalité. TDD är bara ett verktyg för att höja kvalitén och fokus ska nog ligga på kvalité snarare än att tala sig varm för TDD.
Men Dag du är ju i en ypperlig situation. Många lyssnar på vad stora framgångsrika företag gör och vill göra samma sak. Så i skedet att övertyga om TDDs förträfflighet för att höja kvalitén kan du alltid peka på vad din arbetsgivare lyckas med tack vare TDD... :-)
Posted by: Cellfish | 2008-12-26 at 18.55
Insåg att jag inte sade det uttryckligen, men med högre kvalité utgår jag ifrån att totalkostnaden under en applikationslivstid blir mindre jämfört med sämre kvalité.
Posted by: Cellfish | 2008-12-27 at 09.33
Tackar för den feedbacken. Mycket att fundera på.
/dag
Posted by: Dag | 2009-01-22 at 14.04