TDD kata i XP projekt

TDD kata i XP projekt

EDA270 Coaching

Mads Nielsen zba07mni March 5, 2013

Abstract

När man utvecklar program vill man på ett enkelt sätt kunna testa att det man gjort verkligen gör det som man tänkt att det skall göra. Detta kan man göra genom att skriva tester till det man utvecklar som testar funktionaliteten på programmet.

För att underlätta inlärningen av detta sätt att arbeta på kan man använda sig av TDD-katas där man tränar utvecklarna i att använda test driven utveck- ling som förkortas TDD. Användandet av TDD-kata gör det även lättare för coacher att förstå sig på TDD och gör det lättare för coacherna att lära ut till utvecklarna i ett team.

1 Inledning

Denna djupstudie kommer att baseras på EDA260 PVG projektet och EDA270 Coachning av programvaruteam jag kommer att referera till dessa som projektet och coachning kursen.

Många nya, men även erfarna utvecklare av programvara idag vet antingen inte vad TDD är, hur man skall använda det eller ser ofta TDD som mycket extra jobb som är svårt, tråkig och onödigt att lära sig, inställningen är ofta att

"varför skall man skriva test först när vi ändå skall testa koden sen genom att köra programmet och testa om allt fungerar, det blir ju ändå samma resultat i slutändan." - Planeringsmöte 1

Därför är det viktigt att försöka hitta metoder och verktyg som underlättar för utvecklare att lära sig och förstå innebörden av att använda TDD för att snabba upp utvecklingen och framför allt testfasen av programmet.

Metoden TDD kata[1, 2], kata kommer från kampsportens värld där det är ett förutbestämt rörelsemönster som knyter ihop en mängd olika tekniker, både för att eleven skall visa upp att den har förstått vad den har lärt sig men även som ett sätt att träna eleven på teknikerna som ingår i en kata, utan att man explicit säger att det är de individuella teknikerna man tränar. Detta gör att eleven fokuserar på hur man bygger ihop teknikerna framför att fokusera på de individuella teknikerna.

Mycket likt detta består en TDD kata av ett lätt exempel där man följer ett förutbestämt mönster där man skriver ett felande test först, implementerar kod så att testet blir grönt, utökar testen så att det blir rött igen, implementerar ytterligare funktionalitet tills testet blir grönt. Såhär fortsätter man tills hela katan är klar och man har ett litet program där det finns test som testar all funktionalitet, sedan börjar man om från början igen och arbetar sig igenom katan. Förhoppningen är att utvecklaren inser att tiden för själva testningen av programmet går mycket snabbare när man använder TDD och även att man kan garantera att metoderna faktiskt gör det som de är tänkta att göra.

Kan man genom att själv lära sig TDD kata lättare lära ut TDD?

Blir man bättre på att utveckla TDD om man kör TDD-katas regelbundet?

2 Bakgrund

Alla de studerande som deltar i projektet har även under EDA260 kursens teori del gått igenom de olika delarna av hur ett XP projekt går till, en av delarna är en genomgång av hur TDD fungerar och hur man använder det, denna är dock ganska kort och endast ett fåtal av de studerande greppar detta och förstår det direkt, medans majoriteten uppfattar detta som något som bara måste genomgås för att klara kursen.

Det många kanske inte tänker på är att TDD är en vital del i projektet då det underlättar för teamet. Genom användningen av TDD blir det även lättare att spåra fel när man gör ändringar/tillägg i koden då man alltid har en uppsättning test som täcker den tidigare skrivna koden, som hjälper till att direkt visa att det man implementerat sist faktiskt tar sönder det som tidigare finns implementerat istället för att man först skulle upptäckt detta när man sedan skulle testa programmet. De har även fått prova på vissa delar genom att genomföra laborationer på de bitarna, för att få deltaga i projekt biten av kursen erlägger varje deltagare ett kunskapsprov som måste uppnå godkänt.

Allt detta händer innan jullovet och projektet genomförs först efter jullovet detta kan vara en bidragande faktor till att deltagarna glömmer bort en del av de kunskaper de har lärt sig på teoridelen när de väl skall genomföra detta i praktiken. Detta skulle kunna förbättras och kanske till och med undvikas genom att man lägger både teori-delen och praktik-delen av kursen under samma termin vilket gör att det inte blir något långt uppehåll mellan att man lär sig hur det fungerar till att man får använda det man lärt sig i praktiken.

3 TDD-kata

I denna del kommer jag att diskutera behovet av en metod TDD-kata att lära sig TDD, och även diskutera målet med TDD-kata.

3.1 Behovet av TDD-kata

Agila projekt av typen XP använder sig av koncept som Embrace Change[4], där man inte har en exakt arkitektur när man börjar med ett projekt utan låter den växa fram under tiden som man utvecklar. För att detta skall kunna fungera

måste man ha test som ser till att när man gör ändringar och tillägg i koden inte tar sönder den redan existerande kodbasen.

Behovet av en metod som hjälper utvecklare med inlärningen av att arbeta med TDD är alltid eftertraktat.

Några av dagens företag som fortfarande använder sig av någon form av vattenfalls metoden där utvecklingen är uppdelad i steg och där varje steg är fullt beroende av att föregående steg fungerar, skulle något bli fel måste man gå tillbaka och ändra föregående steg och i värsta fall börja om helt. Att arbeta på detta sätt gör det svårt och mycket kostsamt för kunden att göra ändringar under utvecklingen och kan resultera i att kunden inte får den produkt som den ville ha då det skulle kosta för mycket att göra ändringarna.

Detta är var den agila modellen och i detta fall XP modellen med fokus på TDD är överlägsen genom att man arbetar fram programmet kontinuerligt tillsammans med en kundrepresentant som gör att kunden när som helst kan göra ändringar i produkten för att resultatet skall bli så som kunden vill ha det, när kunden är nöjd med programmet kan den avsluta utvecklingen och börja sälja programmet.

Det som kan vara svårt för många vana vattenfalls utvecklare är att ändra vanan att implementera allt utifrån kravspecifikationen först och sedan imple- mentera test för att testa programmet. Mot att skriva små test först och sedan successivt implementera koden och skriva nya test. På så sätt göra det lättare att sluttesta programmet då det hela tiden finns tester för allt. Detta gör att det även blir lättare att göra ändringar när kunden vill ha fler eller nya funktioner.

3.2 Målet med TDD-kata

Målet med TDD-kata är att underlätta för utvecklare att ta steget från att vara en ”vattenfalls”-utvecklare till att bli en TDD-utvecklare.

Detta kan man göra genom att låta utvecklare köra igenom flera olika kator flera gånger dagligen under en kort period, när man kör en TDD-kata många gånger lägger man fokus på hur man jobbar fram bra kod och bra tester sam- tidigt, istället för att först lägga fokus på att implementera bra kod utifrån kravspecifikationen och sedan lägga fokus på att skriva bra tester utifrån ko- den.

Detta leder till att utvecklaren genom att öva TDD med TDD-kata blir bättre på att skriva bra kod och bra tester utan att lägga fokus endast på den ena åt gången, genom att man förstår detta sätt att arbeta på blir det mycket lättare att byta arbetssätt från vattenfalls-metoden där utveckling och test är skilda processer till att arbeta med TDD där utvecklingen av kod och test sker samtidigt.

4 Experiment och resultatmätning av TDD-kata

Att mäta resultatet av TDD-kata kan jag anse som ganska svårt då det inte går att göra utan att man frågar deltagarna och beroende på deras tidigare erfarenheter kan effekten av TDD-kata vara allt från helt obefintlig till att det är det absolut bästa sättet att lära sig TDD på en rimligt kort tid.

Jag har valt att mäta effekten av TDD-kata på två olika sätt det första genom att använda ett analysverktyg eclEmma[5] som testar hur mycket av den

implementerade koden som täcks av testen. Men jag har även valt att mäta effekten genom att låta deltagarna i projektet svara på en enkät om TDD-kata.

Jag valde att gämföra code coverage mellan alla teamen i kursen efter varje iteration för att få en överblick på hur de olika teamen låg till. Jag väljer att lägga mindre fokus på att kontrollera kvaliteten på testen mellan de olika teamen och endast göra små granskningar på mitt egna team, detta kommer att gås igenom mer grundligt i nästa stycke.

4.1 Experiment

Jag kommer låta deltagarna få relativt fria tyglar under iteration ett för att se hur bra de kommer ihåg det de lärt sig under teoridelen av kursen. Under iteration två och efterföljande iterationer kommer jag att introducera TDD-kata och uppmana alla att prova dessa.

4.2 Verktyg för att mäta test coverage

Verktyget som jag har valt att använda heter eclEmma som är ett plugin till eclipse och som är ett verktyg som analyserar vilka rader som testas när JUnit testerna exekveras. Genom detta får man fram en procentuell andel av koden som testas. Jag valde att använda denna plugin då jag använt den när jag själv genomförde projektet och även då det är väldigt enkelt att använda. Och då denna djupstudie inte handlar om analys av olika verktyg kommer jag ej gå djupare in på detta område.

4.3 Vad kan gå fel?

Det främsta felet som brukar uppstå när man använder ett analysverktyg som eclEmma för att testa hur mycket av koden som är testad är att verktyget kan inte testa hur man kommit fram till resultatet utan endast visa vad man kommit fram till genom att analysera hur mycket av koden som testas i testningen.[3]

Detta kan leda till att man får en skev bild av hur bra teamet är på användandet av TDD så som det är tänkt att användas och endast visar att teamet kan skriva tester som testar koden som är implementerad. Detta kan även leda till att teamet tror att de jobbar enligt TDD konceptet men i verkligheten inte har en aning om hur det fungerar.

Man skall heller aldrig lita blint på ett sådant verktyg då detta endast kon- trollerar vilka rader som testen går igenom och inte att testet verkligen testar dessa rader.[3]

Exempelvis med GUI testning där man i teamet gjorde ett skal test som testade GUI vilket tolkades av eclEmma som om att GUI hade 100% test täck- ning. Vilket sedan sjönk något då man verkligen började skriva det riktiga testet. Detta visar bara på att oavsett hur bra ett analysverktyg är skrivit finns det alltid något som kan misstolkas och leda till ett overkligt resultat.

5 Studie

För att testa hur deltagarnas kunskap och användning av TDD påverkas av användningen av TDD-kata, och kan bidra till att utvecklare blir bättre på att omfamna konceptet TDD och genom detta bli en bättre utvecklare.

Under projektet förekom det en team kod granskning för att undersöka om teamet förstod nyttan av TDD-kata. Det kommer även att delas ut en enkät till de deltagande studenterna i teamet för att undersöka hur de själva upplever att det fått användning av TDD-kata.

5.1 Undersökning

Under den första iterationen fick utvecklarna påbörja projektet utan större in- verkan från coacherna. Detta med mål att låta deltagarna i teamet prova på sina kunskaper från teori-delen av kursen och även få tid att fokusera på att komma igång med projektet. Detta för att deltagarna i projektet går andra året i sin utbildning och endast har läst ett fåtal programmeringskurser tidi- gare, dessutom har det inte jobbat i några större projekt tidigare och att jobba enligt XP-modellen är något helt nytt. Vilket gör att det är ganska mycket på en gång och att en introduktion av TDD-kata skulle bli för mycket på samma gång.

Under den andra iterationen valde jag att introducera TDD-kata och även analysverktyget eclEmma, som används för att mäta test täckning av koden.

Detta användes för att visa för teamet hur mycket de testade men även för att visa effekten av att använda TDD.

5.2 Resultat

Efter första iterationen hade teamet lyckats få en förvånansvärt hög test täckn- ing på 81,1% vilket visade att teamet redan innan vår vägledning hade bra koll på att testa koden de implementerade, även om det visade sig efter en diskussion med teamet att en del tester hade implementerades först efter att koden hade implementerats.

Efter att ha introducerat TDD-kata fick deltagarna en bättre förståelse för hur processen TDD verkligen bör fungera, genom att arbeta fram koden genom användningen av felande test, implementering av kod tills grönt test, utöka test till felande test, implementering av kod tills grönt test osv. Detta med hjälp av GUI testning resulterade i en test täckning på hela 94,7% efter andra iterationen.

Genom användningen av analysverktyget eclEmma fick användarna en bra feedback på att det de gjorde verkligen syntes. Även om högre test täckningen bara var en del av målet med TDD-kata var det stora målet att deltagarna skulle bli bättre på TDD.

5.3 Kata passande för PVG projektet

Under projektets gång valde jag att låta en av deltagarna i projektet utveckla en egen TDD-kata som skulle kunna passa till projektet, arbetet med detta kan ses i appendix A.

Katan bygger på filhantering med java då detta är en väsentlig del av pro- jektet.

5.4 Enkät om TDD-Kata

Enkäten kan ses i appendix B.

Sammanställning av svaren.

2. TDD-katan har hjälp deltagarna att bli bättre på TDD och de har fått en insikt i hur små steg det egentligen är när man jobbar fram koden med TDD.

Det är även bra att man kan köra samma övning flera gånger för att få mer känsla för hur TDD fungerar i praktiken.

3. Det kunde vara bra om man integrera det i kursen exempelvis med att man inför varje iteration fick en ny kata att köra igenom, detta skulle med all sannolikhet leda till bättre utövning av TDD på Långlabbarna.

4. TDD-kata är en bra metod att lära sig TDD eftersom det handlar om små övningar varje gång man jobbar. På så sätt kommer man in i TDD-tänket och kanske skriver bättre tester. Om man övar på att skriva tester blir man bättre på det och om man har något som man vet fungerar är det lättare att överföra till verkligheten. Till exempel om man har en kata som man gör och man vet vilka testfall som ingår i den så kan man lättare skriva liknande tester och vet var man skall börja när man arbetar med TDD.

TDD-kata gör att man blir van med TDD, det gäller att utvecklaren har testning i ryggmärgen före implementering och TDD-kata är övningar som gör att man ständigt nöter TDD.

5.5 Statistik

Datan är insamlad efter 18:00 efter varje iteration och används för att jämföra hur bra code coverage som teamen har och hur denna utvecklas under projektets gång. En sammanställning av datan finns i appendix C.

Som man kan se håller majoriteten av teamen med en genomsnitts code coverage på mellan 60-80% vilket är normalt, då man vanligtvis anser att det är alldeles för resurskrävande att höja code coveragen över 60%[6]

5.6 Team kod-granskning

Under iteration 3 valde jag att genomföra vad vi kallade en team kod-granskning.

Detta gjordes då teamet under iterationen höll många diskussioner kring en klass och efter att jag själv hade granskat den visade sig vara mycket rörig och mycket svårförståelig, för en som inte var helt insatt i den klassen som fanns i repositoryt. Detta ansåg jag att det inte skulle hänt om man jobbat enligt TDD.

5.6.1 Utförande

Coacherna tog rollen som nya utvecklare som skulle ta över projektet. Vi visade upp klassen på en projektor och sedan fick teamet tillsammans förklara vad denna klassens metoder gjorde. Hur dom med hjälp av TDD hade utvecklat dessa metoder, för att vi skulle förstå klassen och enkelt kunna vidareutveckla programmet.

5.6.2 Resultat av granskning

Det visade sig att endast ett fåtal av utvecklarna hade så pass bra koll att de verkligen visste vad dessa klassers metoder gjorde och kunde förklara detta för

oss coacher. Det kom även fram att om man hade jobbat strikt efter TDD skulle man nog gjort metoderna mycket lättare och använt ett design mönster istället för att lägga allt i en metod. Men att man valde att implementera kod som gjorde det man ville och sedan testade man att metoderna gjorde det man trodde.

Teamet diskuterade även fram att om man använt sig mer av TDD-kata och verkligen förstått principen med TDD, att man då troligtvis fått en mycket bättre klass med små enkla metoder som var och en hade ett tydligt syfte och funktion, istället för två långa metoder som gjorde allt.

Granskningen ledde till att teamet fick en bättre förståelse varför det är viktigt att jobba enligt principen TDD där man först tänker igenom vad man vill göra sedan skriver ett test för det, implementerar kod, test, implementation tills storyn är klar. Det som teamet missade var att man efter denna process bör refaktorisera obarmhärtigt.[4] Att man inte gjorde detta ledde till de långa och onödigt krångliga metoderna som teamet efter granskningen förstod att man kunde gjort mycket enklare genom att man följt TDD helt och inte bara nöja sig med ett grönt test.

Resultatet av detta blev en väldigt omfattande refaktorisering som utfördes på spike tid och som resulterade i att teamet jobbade mycket effektivare under iteration 4 där de hann med allt som kunden hade prioriterat.

6 Sammanfattning

Jag känner själv att jag fått en djupare förståelse för hur TDD fungerar och utifrån detta känner jag att jag blivit bättre på att lära ut TDD genom TDD- katas. Jag har även fått en bättre insikt i hur små steg det är man egentligen gör när man utvecklar med TDD.

Överlag uppfattar jag det som om att teamet blivit bättre på att använda TDD och att gått från att inte riktigt veta hur till att kunna förklara för mig hur man använder TDD.

Jag anser att det skulle vara bra att när man i den teoretiska delen av kursen gick igenom TDD att man även presenterade TDD-kata. För att visa att även om det kanske inte är det roligaste att lära sig, att det faktiskt finns metoder som gör det lättare för en att lära sig det. Detta skulle man kunna göra genom att dedikera någon övning till att träna på TDD-kata. Vilket skulle bidra till att deltagarna får en bättre förståelse för TDD och lättare kan använda detta under projektet.

References

[1] Exempel på TDD-katas

http://codekata.pragprog.com/codekata/. Hämtad 2013-03-03 [2] Filmatisering av string calculator kata

http://vimeo.com/8722480. Hämtad 2013-03-03 [3] Brian Marick, How to Misuse Code Coverage

http://testingeducation.org/BBST/foundations/Marick_coverage.pdf.

Hämtad 2013-02-15

[4] Kent Beck, Embracing change with extreme programming, IEEE Computer, 2002 s. 70-77.

http://dx.doi.org/10.1109/2.796139. Hämtad 2013-02-15 [5] EclEmma

http://www.eclemma.org. Hämtad 2013-02-18

[6] Qian Yang, J. Jenny Li, David Weiss, A survey of coverage based testing tools, Proceedings of the 2006 international workshop on Automation of soft- ware test.

http://dx.doi.org/10.1145/1138929.1138949. Hämtad 2013-02-18

A Kata för PVG

A.1 Inledning

Stor del av testningen vi har utfört i kursen har vi gjort på kod som ska hantera filer. Både Därför kan en kata för sådana algoritmer vara bra så att man lär sig hur dessa kodstycken ska testas. Detta är ett första försök från mig att skriva en kata så den kanske inte är optimal, om man verkligen till utföra en kata är det bättre att använda någon av de som finns att hitta i Spiken om TTD-kata eller på internet. De är skrivna av folk som vet vad de håller på med.

A.2 Metoden för att få fram katan

När jag började utveckla denna kata visste jag inte hur de fungerade så jag var tvungen att göra lite efterforskningar på internet. Jag läste den spike som någon annan gjorde för några veckor sen och leta runt lite på internet för att hitta exempel. Det jag kom fram till var att de olika katorna var definierade på olika sätt, men de flesta beskrev olika testfall som skulle utföras. De skulle göras en i taget och helst ska man inte läsa i förväg.

Efter detta kom jag fram till några punkter som man kunde använda sig av för att bygga upp katan:

1. Inget funkar 2. En del funkar 3. En annan del funkar 4. Allt funkar

Detta kan naturligtvis utvecklas till flera punkter, man detta var grunden jag utgick ifrån. Därefter började jag utveckla de olika punkterna för att passa till den kata jag ville skriva. Det blev något i stil med det här:

Som början kan man ha filen inte finns. Då ska det till exempel skrivas ut felmeddelanden och programmet ska inte krascha.

Som andra kan man ha att filen är tom som man försöker läsa. Detta är en bra start då man jobbar med det minsta möjliga som testet ska utföra.

Därefter kan man gå vidare till ett enkelt fall. Det finns en rad att läsa. Det ska går enkelt att testa om man från början vet vad som står.

Till sist kan man läsa hela filen och på så sätt avsluta testningen för denna enkla kata.

För att utföra den gör man ett steg i taget och skriver testet, ser att det misslyckas, skriver koden och ser att testet fungerar. Detta gör man för varje steg i katan tills man är klar.

A.3 Själva Katan

För att sammanfatta detta och göra en enkel kata av det hela blir det kanske något likande detta:

1. Denna kata bygger på filinläsning som är en stor del av PVG-projektet.

För att utföra katan behöver man ett enkelt filinläsningsprogram. Men tänk på att detta är TDD, så man skriver testen först.

2. Det enklaste fallet är när det inte är något fall, dvs att filen inte finns.

Om filen inte finns ska ett passande felmeddelande skrivas ut, till exempel

”Filen hittades inte”.

3. Nästa fall är att filen är tom. Då hittar man filen men det står inget i den. Eftersom detta är till PVG-projektet kan det vara passande med en utskrift så som ”Inga deltagare” eller ”Inga tider”.

4. Nu går vi över till att faktiskt läsa in text. Till en början är det tillräckligt att läsa in endast en rad. Detta kan vara något sådant som ”1; A Asson;

”tid; ”tid” ” osv.

5. Där man vet att det går att läsa in och allting annat fungerar återstår bara att läsa in hela filen med alla namn, tider och överskrifter. Om allting har gått som det ska borde detta inte vara något problem.

Denna kata kan man naturligtvis bygga vidare på t ex att vissa formatering ska gälla eller att vissa tecken inte är tillåtna. Man kan även göra en liknande som bygger på utskrift istället för att läsa.

A.4 Avslutning

För att sammanfatta det hela kan jag säga att det var intressant att läsa och skriva om tdd-kata. Dessutom skulle jag tro att tdd-kata hjälper mycket om man är dålig på att jobba med tdd. Som vi alla har märkt under kursen så har vi ibland varit dåliga på att skriva testen först, om man hade jobbat med mönster på detta sättet skulle det säkert gått bättre. Jag skulle till och med gå så långt att man borde göra detta till en obligatorisk del av kursen till nästa år.

Att det finns någon sorts kata som alla ska göra i början av långlabben för att få igång tdd-tänket och jobba med det under dagen.

B Enkät

1. Har du provat TDD-kata? -Om nej se/prova. (stringcalculator http://vimeo.com/8722480) 2. Har TDD-kata hjälpt dig att bättre förstå och lära dig TDD? -Hur?

3. Tror du att det kan vara nyttigt att TDD-kata är en del av teoridelen på kursen? -Varför?

4. Beskriv varför/varför inte TDD-kata är en bra metod att lära sig TDD.

C Code coverage data

Team Itr1 Itr2 Itr3 Itr4 Itr5 Itr6 Average 1 76,3 66,8 58,6 60,4 55,1 67,6 64,13 2 70,6 68,2 61,6 67 72,4 83,4 70,53

3 – – 55,6 57,2 57,5 31,0 50,33

4 – – 81,2 78,4 80,6 94,8 83,75

5 74,3 84,4 98,3 91,9 92,5 – 88,28 6 61,2 78,2 74,7 87,7 – 80,8 76,52 7 70,1 64,7 66,3 79,4 79,9 79,6 73,33 8 66,9 60,7 59,9 72,3 72,9 76,6 68,22 9 69,7 85,3 66,3 59,4 82,6 – 72,66 10 65,1 83,8 67,3 66,1 68,7 65,2 69,37 11 61,1 71,8 51,5 66 72,4 70 65,47 12 81,1 94,7 88,7 95,5 90,9 91,1 90,33