Varför ska man arbeta testdrivet – varför ska man använda TDD och BDD?

Varför man ska arbeta testdrivet?.. Jo Därför!.

Okej, jag kan väl komma på några motiverande punkter om du behöver hjälp att övertala någon annan. 😉

Pengarna – Ju tidigare ett felaktigt eller missat krav upptäcks desto billigare blir det att åtgärda.

Ofta när jag arbetar testdrivet hittar jag luckor i testerna (kraven) som då kan bollas tillbaks till beställaren.
Utan dessa tester passerar många av luckorna i kraven, för det finns nästan alltid luckor i kraven, till manuell testning (utförd av en utvecklare eller testare) och ibland även vidare till beställarens acceptanstester och i värsta fall ända ut till produktion.
Missade och feltolkade krav är defekter och orsakar en onödig kostnad som kan bli galet hög i form av försenade leveranser, förlorade marknadsandelar, bristande förtroende till varumärken och inblandade parter o.s.v..

Kontraktet och bonuseffekterna.

Genom att arbeta behovs- och testdrivet får vi skriftliga krav direkt i koden på hur systemet ska fungera. Dessa krav bör godkännas av beställaren innan man går vidare till utveckling och blir då ett kontrakt som visar svart på vitt vad utvecklingsteamet behöver göra för att jobbet ska kunna godkännas. 

Just kontraktet mot dig som utvecklare är ett fantastiskt kraftfullt stöd och ger tydliga ramar för vad som ska göras. Eftersom programmeringen i sig gör att vi systemutvecklare lätt får tunnelseende och spårar ur med onödig funktionalitet, YAGNI, underlättar det enormt att ha en guide att förhålla sig till.
Genom att arbeta metodiskt utifrån kontraktet och först skriva villkoret som ska uppfyllas och därefter skriva koden som behövs för att uppfylla villkoret, endast villkoret och inget mer, begränsas vi till att inte skriva onödig kod; alltså styrs vi in på en väg mot ren kod och bra kod.

När kraven sen är uppfyllda och implementationen har acceptanstestats samt godkänts av beställaren har vi, förutom kontraktet, automagiskt även en dokumentation över hur systemet just nu fungerar, helt enligt kraven så klart.

Som du förstår är det väldigt skönt att kunna luta sig mot kraven om beställarna kommer med klagomål över hur systemet beter sig, men bäst av allt är att kontraktet gör det mycket lättare för oss utvecklare att våga göra förändringar i systemet eftersom vi när vi kör testerna kan se om något gått sönder, d.v.s att systemkraven inte längre uppfylls, och då kan åtgärda felen direkt.

Behåll kompetensen och rekrytera enklare

Det blir roligare att arbeta med systemet vilket gör att personalen stannar längre och därmed är det också lättare att rekrytera nya medarbetare. Och som en ytterligare bonuseffekt går det mycket fortare att lära upp de nya utvecklarna i systemet eftersom de snabbt kan få en överblick av hur det fungerar, dels genom att läsa kraven och dels genom att följa stegen, ”debugga”, i testfall och scenarion.

 

Som jag sa.. Därför! :)

Kontrakt + dokumentation + tester + ren kod  ~ bra kod ~ billigare förvaltning, glada medarbetare, nöjda kunder!

 

Boktips: Clean Code, The Clean Coder, the art of Unit testing

Clean Code, Clean Coder, the art of Unit Testing

clean requirements and clean code

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *