Vad tjänar man på jobba med TDD jämfört med att skriva testen efteråt? I båda fallen skriver man test för samma funktioner och kan få samma code coverage.

TDD leder ofta till bättre design och mindre buggig mjukvara. Anledningen är att utvecklare inte motiverade att hitta felen i sin kod utan bara visa att den som fungerar.

Vad finns det för problem med att arbeta med TDD? Det är en ganska hög tröskel för att komma igång med det. Dom tre största inlärningsmomenten är:

·         Lära sig skriva bra enhetstest

·         Lära sig att låta testen driva utvecklingen (TDD)

·         Lära sig att göra en bra design

I den ordningen är det bra att lära sig momenten också.

Vad är det då som gör ett test bra? Framförallt är det att det är lättläst test där det är tydligt vad det testar. Det är absolut inte ett krav att ett test ska testa all funktionalitet i en klass utan hellre flera lättlästa korta test som tydligt testar olika delar av klassen.

I nästa blogginlägg ger jag exempel på hur man kan driva designen med test.

En best practice för att det ska vara bra design är att följa S.O.L.I.D

·         Single Responsibility Principle (SRP)

·         Open Closed Principle (OCP)

·         Liskow Substitiution Principle (LSP)

·         Interface Segragation Principle (ISP)

·         Dependency Inversion Principle (DIP)

För att hitta bra förklaring och översikt över principerna kan man titta in på: http://www.lostechies.com/blogs/chad_myers/archive/2008/03/07/pablo-s-topic-of-the-month-march-solid-principles.aspx

Som med allt annat så är bästa sättet att lära sig samtliga delar att öva. Sen är det klart att det kan gå lite fortare och vara roligare om man har någon mer erfaren i teamet som man kan fråga och få guidning av.