TDD – Test Driven Development
Testdriven utveckling (TDD) säger att man först skriver ett test som fallerar (viktigt), sedan implementerar man så att det inte längre fallerer. Efter det inspekterar man designen och koden för att säkerställa att den är enklast möjliga. Om inte så fixar man det, utan att ändra vad koden gör – refactor på engelska. Eftersom de tester man har går igenom så är det tryggt att ändra implementationen.
Det finns flera poänger med detta:
- Ett test beskriver vad som skall göras medan implementationen beskriver hur det ska göras. Testerna blir därmed specifikationer skrivna i ett formellt språk, Java (eller vad som gäller för projektet).
- Eftersom testet skrivs innan implementationen så blir designen av gränssnittet gjort utifrån en brukare (testet) vilket blir bättre än om det görs med utgångspunkt i hur implementationen är utformad.
- Testerna blir verkligen skrivna, vilket inte är fallet om man skriver dem efteråt. Täckningsgraden för tester skrivna efteråt blir dessutom betydligt lägre eftersom det oftast blir svårt att komma åt delar av implementationen. Motivationen är extremt låg att skriva tester för kod som man tror fungerar.
Att det finns automatiskt exekverande tester är en kritisk framgångsfaktor. All kod behöver förändras, man kan säga att underhåll av en kodrad egentligen börjar så fort den är skriven. Med automatiserade tester kan man ändra i befintlig kod med större trygghet. Testerna specificerar ju vad som är korrekt så om man ändrar något som går utanför det, så märker man det direkt.
Se även Per Lundholms videoserie ”TDD på svenska” på vår YouTube-kanal samt hans blogginlägg: http://blog.crisp.se/2010/03/03/perlundholm/tdd-illustrated