Analysverktyg för kod och test EDA270 Coaching Emil Einarsson dt07ee3 2012-02-27
Abstract Undertiden som man utvecklar programvara vill man på ett eller annat sätt kunna säga på ett så enkelt sätt som möjligt att det man gjort funkar. Detta brukar man många gånger göra med hjälp utav tester i olika former. För att underlätta testskrivandet och granskningen utav den kod som blivit implementerad så brukar man använda sig utav någon form av analysverktyg som kan presentera olika sorters data beroende på vad det är för sorts verktyg och vad det är användaren önskar sig få fram. Denna studie fokuserar på analysverktyg för testfall och därför används ett specifikt program, EclEmma [3], som en del av en empirisk studie. 1. Inledning I dagens samhälle finns det programvara inuti i princip allt elektroniskt som existerar. Samtidigt som andelen elektronik med programvara ökar så ökar även komplexiteten utav programvaran för dessa elektroniska apparater (tänk bara på hur mycket mobiltelefonerna har utvecklats under de senare åren). Detta innebär att det blir svårare och svårare att på ett enkelt sätt kunna säga att systemet fungerar som tänkt och det blir svårt att se om man förstört gammal funktionalitet under vidareutveckling av en produkt. För att hjälpa till med detta skriver man olika former utav tester, men att kunna skriva bra testfall som täcker in alla krav som ställs på systemet så att man samtidigt håller koll på gammal funktionalitet under utvecklingen av ny är svårt och kräver en hel del kunskap. Oberoende på om man anser sig ha den rätta kunskapen eller inte för att skriva bra testfall så måste man ställa sig frågan: Vet jag att de tester som görs på systemet verkligen testar all kod och innesluter alla möjliga scenarion som kan inträffa?. Detta för oss in på ämnet för denna djupstudie, nämligen analysverktyg. Den här artikeln är framtagen som en del i kursen Coaching av programvaruteam vid Lunds tekniska högskola och är tänkt att ge en djupare förståelse för analysverktyg, hur man väljer rätt och hur man använder det på bästa sätt. I bakgrunden till alla åtaganden och slutsatser inom kodning så kommer programmeringsspråket java att vara det enda språket i åtanke. Detta för att det är det språket som använts i kursen och det känns därför mest logiskt att utgå från det. 2. Bakgrund När man testar system så brukar man tala om två olika sätt att testa, nämligen black-box testning och white-box testning [2]. Black-box innebär att man inte vet något om hur systemet är implementerat och utformar tester för att se att systemet utför det man vill att det ska göra (typiskt exempel är användarscenarion). White-box däremot innebär att man har tillgång till hur systemet är implementerat och testerna utformas för att se att alla metodanrop och liknande ger de resultat som man förväntar sig (typiskt vad som utförs 2
under utvecklingen för att styrka att systemet fungerar). I denna artikel kommer vi endast diskutera white-box testning. För att undersöka hur testningen på ett system påverkas med hjälp av analysverktyg har en undersökning gjorts under ett projekt som jag har varit coach för. Kursen som jag läste heter Coaching av programvaruteam och ges som en valfri kurs det fjärde eller femte året på civilingenjörsprogrammet för datateknik på Lunds Tekniska Högskola (LTH) och går ut på att man ska lära sig hur man coachar ett utvecklingsteam både i teorin och i praktiken. I samband med att det var en praktisk del i kursen så gick även en annan kurs parallellt med denna som heter Programvaruutveckling i grupp, eller kort pvg, som istället går ut på att lära sig jobba i små team på 8 10pers och utveckla en produkt enligt modellen för Extreme Programming (XP-modellen) [5]. Pvg-kursen ges andra året på datateknik på LTH så man kan redan förutsätta att ev. kodvana bland deltagarna är relativt låg. Systemet som skulle implementeras var ett system för att hantera tidtagning och resultatberäkningar för lopp inom sporten enduro. Projektet var uppdelat i sex iterationer där varje iteration var en långlabb (klockan 08.15 17.00) varje måndag plus ett planeringsmöte på två timmar varje vecka. Projektet gick som sagt ut på att använda XP-modell och därigenom TDD (Test Driven Development) vilket betyder förenklat att man skriver testen för något man ska implementera först och sedan skriver man den faktiska koden och ser att testerna går igenom. Det är främst av denna anledning som det kändes naturligt att införa en studie över hur arbetet påverkades i projektet med och utan ett analysverktyg. Därför fick gruppen som jag coachade först arbeta utan hjälp utav något analysverktyg och för att under iteration 3 (tredje långlabben) införa ett analysverktyg och kolla på skillnaderna i hur mycket kod man testade och hur bra den testades. 2.1 Analysverktyget Det verktyg som användes vid undersökningen till denna artikel var en instickningsmodul till utvecklingsmiljön Eclipse som heter EclEmma [3]. Instickningsmodulen har två olika funktioner, dels kan man köra det på alla tester och då få fram hur stor andel av koden som exekveras av de testfall som är skrivna. Det andra sättet är att starta instickningsmodulen i samband med att man vill köra systemet och testa det manuellt, EclEmma lagrar då vilka rader kod som man exekverar under tiden som systemet körs. När man sedan stänger ner programmet presenterar instickningsmodulen data över hur stor andel utav koden som exekverades vid användningen. Det är främst det första användningssättet som är intressant i denna artikel, främst för dess enkelhet och för att det är den delen av instickningsmodulen funktionalitet som används när man arbetar med TDD. EclEmma valdes främst av den anledningen att jag använt mig av den instickningsmodulen tidigare och kände därigenom till den och visste hur den fungerade. Rent teoretiskt sätt så skulle man kunna tänka sig att det skulle vara relativt enkelt att lära sig ett annat analysverktyg, men på grund av tidsbrist och annat som kommit i vägen blev det endast 3
EclEmma som kördes, så någon djupare analys mellan verktygen kommer inte tas upp i denna artikel. Några exempel på andra verktyg som också testar code coverage är Clover, JTest, Agitar och Cobertura [2]. 3. Analysverktyg Analysverktyg är olika former utav verktyg som man använder för att analysera det system som man utvecklar. På vilket sätt verktyget analyserar och vad den presenterar för användaren är helt beroende på vad det är för typ utav verktyg. Det finns relativt många olika sorters verktyg och alldeles för lite tid att gå in på alla, därför kommer vi främst kolla på analysverktyg för test och jämföra det med några andra verktyg som kollar på te.x. bad smells in code (ett uttryck som Fowler har myntat i sin artikel Refactoring: Improving the Design of Existing Code [6]). 3.1 Analysverktyg för test Med analysverktyg för test brukar man mäta hur stor andel av koden som man testar i procent och kalla det för code coverage. Det finns många olika sätt att mäta andelen testad kod och därför är det en viktig detalj att ta reda på för det analysverktyg som man tänker använda sig av. Det absolut vanligaste och enklaste är att verktyget kollar vilka rader kod som blir exekverad av tester och vilka som inte blir det, som tillsammans bildar andelen testad kod (code coverage). Ett mer avancerat sätt att mäta andelen testad kod är att använda sig av multiple condition coverage, vilket innebär att alla logiska uttryck granskas så att de har blivit testade för både sant och falskt [4]. Lägg dock märke till att condition coverage bara anser delar med logiska uttryck och inte annan kod, det vill säga den kommer inte köra igenom och kolla så att all kod är testad, utan bara de logiska bitarna. Det är därför vanligt att de båda kombineras i ett analysverktyg. Oberoende av hur verktyget tar fram andelen testad kod så kommer det produceras ett resultat som presenteras för användaren. Med hjälp utav detta resultat kan man som utvecklare sedan skriva bättre testfall alternativt fler testfall där det behövs. Detta underlättar utvecklingsprocessen i den mening att man i ett tidigt skede kan upptäcka buggar (genom i detta fall inse vilken del av koden som man aldrig testar). Man bör dock se upp med informationen som verktyget ger och inte bara blint skriva testfall så att varenda rad blir uppfyllt eller så att alla logiska uttryck testas i alla möjliga kombinationer. Anser man som utvecklare att det inte finns något behov av att testa en specifik del av koden så bör man inte göra det. Hur stor del testad kod är inget som kunden i slutändan kommer bry sig om i vilket fall som helst, utan bara hur bra systemet fungerar och att det är utan några buggar. Man bör också tänka på att om ett analysverktyg kan hitta delar av kod som är dåligt testad så är det också sannolikt att det finns delar som är svagt testade på ett sätt som verktyget inte kan hitta [4]. Dessutom är analysverktyg för bland annat code coverage något som ensamt inte kan styrka att ett system alltid kommer att fungera, till exempel så innebär inte 100 % code coverage att systemet kommer fungera till 100 % av gångerna. 4
3.2 Andra analysverktyg Utöver verktyg för test finns det även andra sorters analysverktyg som kollar på andra saker i koden. Ett bra exempel är verktyg som kollar efter så kallade bad smells in code, kod som luktar illa, det vill säga kod som är fult implementerat och svår att förstå sig på. Ett exempel på ett sådant program är jcosmo, som används för utvecklandet av artikeln Java Quality Assurance by Detecting Code Smells [1]. Sådana verktyg har dock en skild problematik inom sig i förhållande till verktyg som testar code coverage. Främst har vi problematiken att illaluktande kod främst är något subjektivt som kommer från erfarenheter och åsikter och därför kommer i regel inte en person tycka att ett kodstycke luktar illa som en annan person kanske tycker det gör. Vad som är tanken med den här sortens analysverktyg är att istället för att tala om för användaren att de här delarna har du inte testat, så ska användaren istället få upp ett resultat på delar som eventuellt kan vara dåligt skrivna och/eller som behöver refaktoriseras. Ett konkret exempel på hur man kan hitta olika typer av illaluktande kod med verktyget jcosmo (som letar efter illaluktande kod) är med hjälp av instanceof[1]. Med instanceof menas att man kollar koncentrationen av instanceof operatorer i ett och samma kodblock och om det är en väldigt hög koncentration så dras slutsatsen att det kan vara bra att införa en arvs-hierarki eller att man bryter upp metoden i mindre metoder som får en uppgift istället för många. 3.3 Behovet av analysverktyg Eftersom testning används för att bestämma och förbättra kvaliteten på mjukvara är det en väldigt viktigt del i utvecklingen [1]. Det har även visat sig vara väldigt resurskrävande att utforma tester för systemen och kostnaderna har visat sig ligga upp över 50 % av de totala kostnaderna för ett systems utveckling [2]. Eftersom kostnaderna för testning ligger så högt har man insett att verktyg är betydelsefulla för att göra denna process smidigare, mindre resurskrävande och i slutändan kan det vara verktyget som är avgörande om systemet blir färdigt till deadline. Kostnaderna kommer från att det tar ganska så lång tid att komma på bra test och när man väl ska uppfylla dem så kan det hända att man måste skriva någon form utav hjälpmetoder för att kunna testa specifika saker. När kostnaderna för testningen är så höga har det även börjat utvecklas analysverktyg som genererar testfall utan att utvecklaren behöver skriva några från början. Detta är mer avancerade verktyg och om man inte har koll på vad det är för testfall som genereras så kan det göra att koden inte testas på det sätt man tror. Utnyttjar man ett sådant verktyg får man lägga ner tid på att granska testfallen som genereras istället, men huruvida det tar längre tid att granska testfall eller att skriva dem själv från början är inget som kommer tas upp i denna artikel. Alternativet är att man låter systemet generera testfall och sedan kör dem och sparar undan resultatet för att få till regressionstestning. Efter att man gjort en ändring i koden kan man kontrollera att systemet ger samma resultat för dessa testfall och samtidigt generera nya. 5
3.4 Vad man vill uppnå Med användandet av analysverktyg vill man uppnå så hög code coverage som man bara kan, det vill säga så stor andel testad kod som det bara är möjligt. Tillsammans med det följer även att man vill ha ett system som är så fritt från buggar som möjligt så tidigt i utvecklingen som möjligt. Detta för att hålla kostnaderna nere eftersom det i regel är billigare att rätta till ett fel innan systemet vuxit sig för stort eller efter att ett system har lanserats. Fastän man anser sig vara noga vid testning och att allt ska vara testat så brukar man rimligtvis ha en code coverage på mellan 60% - 70%, vilket brukar vara acceptabelt eftersom det vanligtvis anses alldeles för resurskrävande att höja det över 60% [2]. Utöver detta vill man sänka kostnaderna för testningsdelen av utvecklingen så att man kan leverera ett buggfritt system snabbare och därigenom till ett lägre pris. Snabbt och enkelt skulle man kunna säga att allt handlar om pengar (och då menar jag allt här i världen), utvecklingen ska kosta så lite som möjligt så att cheferna blir glada och kan sälja en produkt med så mycket vinst som möjligt samtidigt som kunden vill ha en produkt till ett så billigt pris som möjligt. Aldrig är det någon som blir nöjd heller, utan man strävar hela tiden efter att få eller skapa så mycket som möjligt för en så liten summa som möjligt. En fråga som du som läsare bör ställa dig är: Hur skulle utvecklingen inom analysverktyg, eller rent av all utveckling, se ut om det inte var effektivisering för att tjäna in pengar som drev den framåt? Vad skulle annars driva den framåt? 3.5 Hur det kan gå fel Code coverage är inget allvetande svar som presenteras på hur man bör förbättra sina test för att säkra att systemet är helt testat och funktionellt. Code Coverage talar bara om vilka rader kod som blivit exekverade av de test som finns och därigenom kan man inte göra antagandet att hög code coverage säger att systemet är testat för alla tänkbara scenarion. Samma sak inträffar om man implementerat funktionalitet på ett inkorrekt sätt och som man sedan dessutom testar på fel sätt, då kommer hög code coverage inte alls säga något om hur funktionellt och stabilt systemet är. Om man är duktig på att skriva bra testfall och är noggrann med vad man sysslar med så borde det dock inte kunna inträffa, i den bästa av världar. Vill man i det sistnämnda fallet garantera sig att systemet i sin helhet utför den tänkta uppgiften så kan det vara lämpligt att fundera på eventuella Black-box tester. 6
4. Empirisk studie För att undersöka hur code coverage påverkas inom programvaruutveckling om man använder sig av ett analysverktyg eller inte så infördes det i ett programvaruutvecklings team i kursen Programvaruutveckling i grupp som ges på LTH. 4.1 Undersökningen Från start fick utvecklarna i teamet skriva testfall för systemet efter bästa förmåga utan hjälp av några analysverktyg. Detta med anledning av att deltagarna i teamet gick andra året på datatekniksutbildningen och därför inte läst så många programmeringskurser tidigare, så de kunde behöva lite tid att komma igång med projektet när allt var nytt istället för att införa allt på en gång. Förutom det hade deltagarna inte jobbat i större projekt tidigare och heller aldrig använt sig av XP-modellen med tillhörande testdriven utveckling. När deltagarna hade kommit igång bra och fått in en bra rutin på hur arbetet skulle flyta på så ansåg jag det vara dags att införa analysverktyget till dem för att de skulle kunna börja se hur mycket de egentligen testade. Vi hade nu kommit in på iteration tre, dvs. den tredje långlabben i projektet. 4.2 Resultat Redan efter den första iterationen så hade teamet åstadkommit en code coverage på 74 %, som den för övrigt höll sig på mer eller mindre även under nästa iteration. Efter att ha introducerat analysverktyget för deltagarna på iteration tre höjdes deras code coverage till 83%. Tillgången till ett analysverktyg som kunde tala om för användaren vad som hade missats att testas var något som uppskattades inom teamet som jag coachade och som synes på siffrorna så blev de motiverade till att skriva fler testfall för att försöka få så mycket av koden testad som möjligt. 5. Diskussion 5.1 Allmänt Först och främst är studien som utfördes inte särskilt generell eftersom den utfördes i endast ett team mitt under utvecklingen och bara under utvecklingen av en produkt. För att få en tyngre och mer styrkt studie så hade det varit vettigare att utföra samma sak parallellt på alla team inom kursen och eventuellt även under flera år. Detta hade dock varit omöjligt främst för min oförmåga att klona mig själv eftersom det hade krävt att jag varit delaktig i alla andra team samtidigt som jag skulle sköta mitt eget. Förutom det hade det även krävts att coacherna för de andra teamen inte hade något att säga till om huruvida deltagarna i deras team fick använda analysverktyg eller när de fick använda det. Man kan enkelt dra slutsatsen att i det här sammanhanget hade studien inte kunnat utformas på något bättre sätt. 7
Eftersom kursen är relativt liten och därmed har en begränsning så fanns det inte plats för att under utvecklingen studera huruvida olika sorters analysverktyg kunde ha en inverkan på hur bra systemet fungerade eller hur bra code coverage som uppkom. Hade iterationerna varit längre och projektet i sig varit längre hade man kunnat tänka sig att införa att under varje iteration testa ett nytt analysverktyg för att sedan jämföra hur resultatet blev från en iteration till en annan. Men även det sättet att gå tillväga har sina brister för vad säger att svårighetsgraden och de problem man måste slåss med är lika stora i varje iteration? 5.2 Analysverktyg Analysverktyg är ett väldigt kraftigt hjälpmedel under en utveckling, så länge som man vet hur det ska användas och man är införstådd i hur det fungerar. Vet man inte det så hade man nog klarat sig bättre utan det. Analysverktyg är heller inget som hjälper en användare att garantera att systemet fungerar. Är till exempel testerna dåligt testade och bara utformade för att skapa så hög code coverage som möjligt så kan det mycket väl vara så att det uppkommer buggar senare i utvecklingen som man inte har funderat på. Detta hade vi tydliga exempel på i vårt team där deltagarna lyckats uppnå en relativt hög code coverage, men när det efter iteration fyra önskades en testrelease av systemet till mig och min coaching partner, så upptäckte vi att systemet inte alls fungerade som det var tänkt längre. På något sätt har deltagarna lyckats skriva testfall för att testa så att specifika delar av systemet fungerar, men inte alls tänkt på att testa så att allt fungerar tillsammans. Vilket är ett otroligt bra exempel på att man inte ska lita blint på att fungerande tester innebär att ett system fungerar till 100 %. I artikeln A survey of coverage based testing tools tas det upp att 60 % - 70 % är en rimlig siffra för cod coverage, vilket dock kan uppfattas som ganska lågt i ett projekt där man implementerar TDD, det vill säga alla test skrivs först innan något implementeras. Detta kan man se genom att vårt team hade en code coverage på 74 % utan att använda sig av något verktyg och med hjälp av ett lyckas höja det med 10 % utan några vidare svårigheter. Sen huruvida vårt projekt är för litet eller för enkelt för att man ska kunna dra den generaliseringen eller inte är svårt att avgöra. Man skulle kunna tänka sig att efter hand som att ett system växer sig större blir det svårare och svårare att testa och även om det är meningen att man ska skriva testfall för allt, så är det inte alltid lätt eller rimligt att testa allt. Det blir nog svårare och svårare att få hög code coverage efter hand som systemet blir större och dess komplexitet ökar. 6. Slutsater Analysverktyg är viktiga hjälpmedel för att öka produktiviteten under utvecklingen av programvara. För att de ska vara användbara är det viktigt att folk lär sig hur de fungerar innan de använder sig av dem och att de som använder dem inte litar blint på allt som verktyget säger utan istället mer ser det som en rekommendation. 8
Referenslista [1] van Emden, E., Moonen, L. (2002). Java quality assurance by detecting code smells, Reverse Engineering, 2002. Proceedings. Ninth Working Conference on, s. 97-106. <http://dx.doi.org/10.1109/wcre.2002.1173068> [2] Qian Yang, J. Jenny Li, David Weiss. (2006). A survey of coverage based testing tools, Proceedings of the 2006 international workshop on Automation of software test. <http://dx.doi.org/10.1145/1138929.1138949> [3] EclEmma. Retrived 6 December 2011, from http://www.eclemma.org [4] Brian Marick (1997). How to Misuse Code Coverage, Retrived 6 December 2011. <http://testingeducation.org/bbst/foundations/marick_coverage.pdf> [5] Kent Beck (2002). Embracing change with extreme programming, IEEE Computer, s. 70-77. <http://dx.doi.org/10.1109/2.796139> [6] M. Fowler (1999). Refactoring: Improving the Design of Existing Code. Addison-Wesley. 9