Det fanns en serie argument mot TDD.
- Jobbigt
- Ta längre tid
- Dubbla kodbaser.
Jobbigt.
TDD har sina rötter i XP. I XP så kodar man aldrig ensam. Pair programming (PP) är en disciplin i sig som tvingar utvecklarna att följa ett visst förhållningssätt.
I PP har man två uttalade roller, driver och navigator. Rollen navigator indikerar just det som gör TDD möjlig. Förutsättningen är att man vet vart man är på väg, åtminstone i grova drag. Kanske har man skissat upp sin domän och vet vad man måste lösa. Hela user storyn har brutits ner i mindre delar och man angriper en isolerbar del.
Detta gör att navigatorn inte sitter bak din rygg och idlar, utan har koll, förståelse för vart man är och vart man är på väg.
Traditionell utveckling sker mer ad-hoc. Man kodar själv och vet vad man måste lösa, men uppgiften man antar har oftast ett större scope. Utvecklingen kanske adresserar allt från persistens till ui (webb utveckling).
Man har dessutom sällan skissat på en domän modell och ändamål (cohesion) för de klasser man skapar brukar vara låg. Argumenten för detta är ofta något i stil med: -Äh, jag måste bara få det att funka!
Det faktum att man inte på förväg kan säga, ungefär, vilka beroenden man måste mocka bort gör hela processen jobbig.
För att få arbetet mindre jobbigt så behövs det disciplin och en modell. Använder man sig Domain Driven Design (DDD) så har man mycket gratis eftersom DDD ger dig strikta förhållningssätt för din kod och TDD ger dig disciplinen Det blir lite lättare att säga vart man borde stoppa logik och vilka beroenden man kan / får ha. Man får implicit kravet på sig att rita lite innan man börjar hacka.
http://www.infoq.com/minibooks/domain-driven-design-quickly
Jag skulle vilja säga att den agila processen som helhet kräver mer av utvecklare. Att skriva enhetstest är bara en del. Borta är den bekväma situationen där man bara bockade av punkter i ett användningsfall och gick hem.
http://www.infoq.com/minibooks/domain-driven-design-quickly
Jag skulle vilja säga att den agila processen som helhet kräver mer av utvecklare. Att skriva enhetstest är bara en del. Borta är den bekväma situationen där man bara bockade av punkter i ett användningsfall och gick hem.
Tar längre tid.
Kort sikt
Man måste skriva mer kod :(
Detta är sant. Men det finns många sätt att få upp tempot på testkodning. T ex kan man köra Kator med målet att lära och tweaka sig sin IDE tills det inte går att göra Katan snabbare.
Om du sätter dig vid en naken installation av Eclipse och känner att du inte kan använda den eftersom det kommer ta två timmar att få den precis som du vill ha den, då har du lyckats. Om du sätter dig vid din preparerade IDE och det sprutar importer och, via templat, genererade metoder, då har du lyckats.
I den situationen är tanken på att starta din runtime i debug mode för att kontrollera varför en metod returnerar fel värde väldigt långsökt. Du går bara till din testklass, utökar den med de testfall du funderar över. Kanske startar du JUnit processen i debug.
Läs gärna artikeln om just detta:
På längre sikt så är TDD en av de fundamentalt viktigaste delarna för att göra ett projekt: förvaltningsbart. Ett väl skrivet enhetstest är en dokumentation som inte blir inaktuell i takt med förändringar i systemet. Det är så enkelt och samtidigt briljant. Varför kom jag inte på det själv istället för att skapa alla dessa main metoder som man sparade lokalt? Jag kunde bott i Kalifornien och haft fyrtio tusen följare på twitter.
Kent Beck - the inventor of tdd. Yet, he claims he just re-discovered it.
Att man vågar förändra koden skall inte vara kopplat med att man har en dödslängtan eller väldigt dålig riksmedvetenhet.
Till det måste kopplas en process för att hantera teknisk skuld i backloggen. Det kan vi ha en diskussion över en öl om närhelst :)
"There is only one way to get to Carnegie Hall-practice, practice, practice!
Kent Beck - the inventor of tdd. Yet, he claims he just re-discovered it.
Att man vågar förändra koden skall inte vara kopplat med att man har en dödslängtan eller väldigt dålig riksmedvetenhet.
Till det måste kopplas en process för att hantera teknisk skuld i backloggen. Det kan vi ha en diskussion över en öl om närhelst :)
Mot kunden
Kunden är i ett fåtal fall medveten om hur du skriver kod. Att sälja in TDD är svårt. Att argumentera för att det kommer att ta längre tid pga TDD är oftast omöjligt. Som utvecklare måste man själv nå den skill som krävs för att det inte skall bli en nackdel utan en fördel."There is only one way to get to Carnegie Hall-practice, practice, practice!
Dubbla kodbaser.
Att mer kod ökar komplexitet och en ökad kodbas är dåligt av ett antal orsaker är sant. TDD genererar otvetydigt mer kod. Kan man rättfärdiga detta?
Jag hittade en rätt rolig artikel som vände på alla argument för TDD. 10 orsaker att undvika TDD:
Läs punkterna och fundera på om din arkitektur är perfekt?
Personligen gör jag fel och jag har dåligt minne. Ett enhetstest är den dokumentation jag behöver för en klass.
Slutsats
Positiva bieffekter
Om man nu orkar köra TDD så finns det ett antal trevliga bieffekter. Bättre separation av kod och beroenden, högre cohesion och ett system som man vågar ändra i.
Visualisering
Har man en CI server så kan man dessutom koppla in olika verktyg för statisk kod analys. Mycket inom agile handlar om att visualisera. En open source produkt som Sonar gör just detta på ett så fint sätt att det är ett ämne för en helt egen Jönköping Developer Dojo eller @jkpgJUG session :)Krav på TDD
Missa inte att koppla ditt bygge till en Continuous Integration server. Där körs dina tester löpande av alla som skickar in kod via något versions hantering.
Försök att ha ambitionen att aldrig bryta bygget!
Å andra sidan...
Finns det en silverkula för allt ?
Har man en avgränsad del, som man bryr sig om. I mitt fall tycker jag om mina favorit appar. De väcker trevliga känslor hos mig och är batteriet urladdat på min telefon så blir jag ledsen. Om jag skulle utveckla den typen av applikationer så kanske jag skulle agera annorlunda. Jag skulle kanske vara mer noggrann och vurma mer för min kod :)
"Are unit tests an invaluable tool for writing great software?" ... "yes."
"Am I going to produce a poor product if I can’t unit test?" ... "no."
Åsikter?
Jag är tex väldigt intresserad i hur man gör i Ruby världen. Samtidigt är det mycket väsen om nästa nivå i testandet, Behaviour Driven Development, där Ruby / Cucumber är hett.
Dessutom har jag till dag dato inte kopplat in JavaScript till någon tdd runner och CI server.
Inga kommentarer:
Skicka en kommentar