Analysverktyg för Code smells och Test coverage. Djupstudie för Coaching av programvaruteam 2015

Transkript

1 Analysverktyg för Code smells och Test coverage Djupstudie för Coaching av programvaruteam 2015 Lund, 6/ Christian Kuijer Andersen Rickard Johansson

2 Innehållsförteckning 1 Abstrakt 2 Nyckelord 3 Förord 4 Problemformulering 4.1 Bakgrund 4.2 Code smells 4.3 Beskrivning av valda verktyg för code smells JDeodorant Eclipse PMD CodePro Analytix Vi valde JDeodorant med följande motiveringar 4.4 Test coverage 4.5 Beskrivning av valda verktyg för test coverage JaCoCo (EclEmma) Atlassian Clover for Eclipse CodePro Analytix Vi valde JaCoCo med följande motiveringar 5 Resultat 6 Diskussion 6.1 Felkällor 7 Slutsats 8 Källförteckning 8.1 Referenser 8.2 Källor 9 Appendix A

3 1 Abstrakt När man utvecklar programvara i grupp och speciellt när man följer utvecklingmetodiken XP (extreme Programming) så är det viktigt att skriva mycket test och ha hög test coverage på koden. Det uppstår ofta bristfälliga delar i koden under projektets gång då utvecklarana gör små fixar för att tillfredsställa kundens ständiga förändringar. Dessa brister i koden brukar benämnas som bad smells och kan vara väldigt svåra och omständiga att granska visuellt, då kan ett analysverktyg för detta vara till stor hjälp. Även test coverage är svårt att granska visuellt eftersom koden kontinuerligt ändras under projektets gång. Ett sådant verktyg underlättar även undersökningen om man testat alla möjliga nästlade vägar i en metod. Vi satte ett mål att ha minst 90% test coverage, som vi inte lyckades nå upp till under projekters gång. Vårt mål var att utvecklarna skulle använda JDeodorant och JaCoCo efter varje story, dock var de dålig användning av JDeodorant, det var bättre men inte fullständig användning av JaCoCo. Vårt resultat var en mjukvara som var stabil och snabbast i tävlingen som ägde rum efter projektets gång. 2 Nyckelord Analysverktyg, Code smells, Test coverage, Kodkvalité, XP,eXtreme Programming, Coaching av programvaruteam 3 Förord Detta är en rapport på en djupstudie där vi har undersökt två olika slags analysverktyg närmare, ur ett urval av fem verktyg. Det ena verktyget är till för att hitta code smells och det andra för att undersöka hur stor test coverage ett projekt har. De två verktygen har använts av ett team bestående av tolv studenter som läste kursen Programvaruutveckling i Grupp (PVG, EDA260) vid LTH (Lunds Tekniska Högskola). Teamet har även två coacher vilka är vi som utfört denna djupstudie som en del av kursen Coachning av Programvaruteam (EDA270) vid LTH. Under sex iterationer utvecklar de studerande, enligt XP, ett system för tidtagning av en enduro tävling. Eftersom parprogrammering används benämns ofta utvecklarna som ett par senare i rapporten. Hela kursen består av 8 team med liknande förutsättningar, men deras coacher bedriver andra typer av djupstudier. Eftersom endast vårt team använde analysverktyg på detta sättet kunde de andra 7 teamen användas som kontrollgrupper då vårt resultat skulle tas fram. En iteration består av åtta timmars arbete som utförs varje måndag i sex veckor och ett planeringsmöte á två timmar mellan varje iteration. Utvecklarna hade också varje vecka en fyra timmars spike uppgift som gick ut på att fördjupa sig i något som kan bidra till att förbättra nästa iterations arbete. Utvecklingen försöker efterlika ett riktigt mjukvaruprojekt och teamet

4 hade därför en person från instutitionen på Datavetenskap som hade rollen som kund. Kunden gav teamet lappar där det var angett önskad funktionalitet på varje iteration, så kallade stories. Under utvecklingen använde sig teamet av en så kallad Kanban board innehållande fyra olika stadier som en story kan befinna sig i. Stadierna är Todo, Implementing, Done och Done done (en story är inte Done done förrän ett annat par har granskat Done koden, kört testerna och undersökt att funktionaliteten som storyn anger verkligen är implementerad). Efter de sex iterationerna så fick teamen tävla med sina programvara mot varandra, där man testar vems programvara som är snabbast och ger korrekt utskrift i en treben tävling runt Sjön Sjön. Rapporten kommer innehålla engelska termer för att inte förvirra läsarna eftersom det ofta inte finns någon bra svensk översättning. 4 Problemformulering Det finns många verktyg som analyserar kod, vi har tagit ut 5 program (2 som endast testar test coverage, 2 som endast testar bad smells och ett verktyg som undersöker både test coverage och bad smells) och sedan analyserat dem noggrannare. De verktyg som vi valt att analysera skulle kunna användas i utvecklingsmiljön Eclipse och vi hade därav kravet att de ska finnas som plugin till Eclipse. När vi hade gjort en djupare analys på samtliga program och själva testat dem valde vi ut ett verktyg för bad smells och ett för test coverage som vårt PVG team skulle använda hela utvecklingstiden. Vår förhoppning var att teamet innan de flyttade över en story till Done skulle köra de två valda verktygen för att hålla sin kod utan bad smells och med hög test coverage. Det vi hoppades uppnå genom att använda analysverktyg var följande: Hög test coverage av all kod Bra skriven kod utan bad smells, så som stora klasser, långa metoder, duplicerad kod och feature envy (funktionaliteten ligger där den behövs). Inte för många grenar i metoderna (undvika nästlade if satser och många villkorssatser) 4.1 Bakgrund Då det är många utvecklare i ett XP projekt så är det viktigt med hög test coverage av koden. Om en utvecklare ska ändra i kod som den inte själv till en början skrivit, kan den använda testerna som en försäkring att koden fortfarande fungerar som den var tänkt till en början. Det kan annars vara svårt att veta vilka andra delar av koden som påverkas av en ändring [2]. Test coverage är även ett bra verktyg för att låta utvecklarna vara säkra på att koden gör vad den verkligen ska göra, och vad utvecklarna har tänkt att den ska göra. Vi satt ett mål till utvecklarna att ha minst 90% test coverage av all källkod under hela projektets gång.

5 Det är viktigt att undvika och minimera bad smells i ett stort mjukvaruprojekt, främst på grund av att det finns många som är delaktiga i koden och att alla i projektet lätt ska kunna sätta sig in i alla delar av koden. Det finns studier på att software maintainers lägger ungefär 60% av sin tid på att bara förstå koden [3]. En kod utan bad smells blir lättläst, självförklarande och det blir lättare för vem som helst att sätta sig in i koden och jobba vidare med den. När man programmerar och vill vara säker på att man får in rätt värde, så kan man kolla det med if satser/if else satser. Dock krävs det flera test fall för att kunna täcka alla möjliga utfall i metoden. Det kan vara svårt att täcka in alla möjliga utfall, utan att behöva skriva en stor mängd testfall. Antalet testfall som krävs för varje nästlad if sats växer med 2 n (n = en if else sats). För att undvika att de studerande skulle tycka att det var omständigt och jobbigt att använda analysverktygen valde vi endast två stycken verktyg som vi dessutom ansåg vara lättanvända. Om vi skulle ha valt ut för många analysverktyg tror vi att risken funnits att studenterna inte använder sig av programmen alls. Efter den sista iterationen fick de tolv studerande fylla i en enkät som bestod av frågor om hur de upplevde analysverktygen och hur mycket det hjälpte dem i projektet. Vårt resultat i rapporten grundar sig även på detta. 4.2 Code smells Det finns flera olika sorters code smells [1], vi har valt att fokusera på nedanstående i vårt projekt: Duplicerad kod Långa metoder Stora klasser Feature envy (funktionaliteten ligger där den behövs) Vi har valt ovanstående code smells eftersom vi själva hade problem med dessa när vi var utvecklare i kursen PVG för två år sedan. Det är även viktigt att undvika dessa brister eftersom de är en del av de grundläggande good pratices som många lär sig när man börjar programmera. Dessutom tror vi att dessa problem uppstår lättare i ett team där utvecklarna har ingen/lite tidigare erfarenhet av XP.

6 4.3 Beskrivning av valda verktyg för code smells JDeodorant 5.0 JDeodorant kan installeras via Eclipse marketplace och visas sedan i menyraden i Eclipse med namn Code smells. När man trycker knappen får man fyra alternativ; God classes, Long metod, Feature envy och Type Checking. När man vill analysera sin kod trycker man på den typ av analys man vill göra, sedan dyker den upp i vyn. Man kan sedan markera önskat projekt/paket/klass och trycka man på det lilla i :et i vyn vilket göra att programmet börjar analysera koden och ger varningar på vad verktyget anser är bristfälliga delar av koden. Programmet kan även föreslå en lösning på de felen som hittas, förslaget ser man genom att klicka på ett problem som JDeodorant har hittat och sedan klicka på knappen bredvid i i vyn som heter Apply refactoring. Man kan då förhandsgranska förslaget och om man accepterar lösningen gör programmet alla ändringar som krävs automatiskt. I JDeodorant kan man inte göra några inställningar av programmet eller ställa in hur det ska bete sig vid analysering av koden. Skulle programmet inte hitta några fel så säger inte programmet till om det utan vyn förblir tom, vilket är vilseledande då man inte vet om programmet har körts och/eller om det har analyserat klart koden. Verktyget testar följande: Långa metoder Duplicerad kod Stora klasser Feature envy Eclipse PMD 1.4 PMD kan installeras via Eclipse marketplace och startas sedan genom att högerklicka på en klass/ett paket/ett projekt och välja PMD i listan som visas. Under den menyn får man olika förslag beroende på om man tittar på en klass, ett paket eller ett projekt. Programmet har 347 regler som den analyserar koden enligt. I huvudsak finns det tre funktioner, check code, clear violations och clear violations review där check code är själva analysen av koden. När man kör check code så dyker det upp en vy med namn violations overview och även vyn violations outline. I violations overview ser man felen kategoriserade i olika kategorier (med olika färgade flaggor framför, för de fem olika kategorierna) och antal fel. I violation outline är varje fel specificerat och har en flagga framför som avspeglar vilken kategori felet tillhör och vilken regel koden bryter mot.

7 Felen delas in i fem olika kategorier och i violation overview så kan man enkelt filtrera ut vilka av de fem kategorierna man vill visa, detta genom att klicka på de fem olikafärgade pilarna (dock stämmer det inte överens med färgerna i violation overview, men färgerna stämmer med färgerna man ser i violation outline ). I violation overview finns det en uträkning på hur många fel det finns i varje kategori, fel per KLOC (per tusen rader kod) i procent och fel per metod i procent. För att få bort dessa flaggor i klassen och i projektet så måste man antingen åtgärda felet, eller så får man högerklicka på den klassen/paket/projektet som man vill ta bort felmeddelande för och klicka PMD och sedan på clear violations. För att göra inställningar i programmet och för att ställa in hur den ska analysera måste man kan gå in Window preference och göra inställningar för vilka regler programmet ska analysera efter. Där kan man klicka på varje regel och få en beskrivning och exempel på hur regeln fungerar. Man kan även importera regler för att utöka de befintliga 347 reglerna. Verktyget testar följande: Buggar (tomma try/catch/finally/switch uttryck) Död kod (oanvända lokala variabler, parametrar och privata metoder) Suboptimal code (onödiga användning av String/Stringbuffer) För komplexa uttryck (onödiga if satser, for loopar som bör bytas ut mot while satser o.s.v.) Duplicerad kod (samma kod skrivet på flera ställen) CodePro Analytix CodePro Analytix är ett analysverktyg utvecklat av Google. Verktyget finns inte i Eclipse marketplace men kan installeras genom att man anger en URL till Eclipse som finns på CodePros hemsida, vilket gör att det laddas ner och installeras. När vektyget är installerad visas en ny knapp i menyn vid namn CodePro. Trycker man på knappen visas flera alternativ. Där kan man få fram diverse guider och knapparna Views, Perspective och Preferences. De vyer som är intressanta för att undersöka code smells är Audit, Metrics, Dependencies och Similar Code. I vyn Audit kan man välja vilket projekt som ska analyseras och det visas då varningar på kodstycken som programmet anser vara bristfälliga. CodePro kategoriserar även varningarna i high, medium och low beroende på hur allvarliga de är. För varje varning visas en beskrivning, förklaring och rekommendation på felet.

8 I Metrics visas mängder med data om projektet, bland annat hur stor del av koden som är abstrakt, medelstorlek på metoder, medelantal parametrar, rader kod, antalet metoder, antalet semikolon och så vidare. De metrics som anses vara för stora eller för små markeras med rött. Under Dependencies kan man få en grafisk vy på beroenden mellan paket och klasser i projektet. Till en början visas beroenden mellan projektet och externa jar filer men man kan klicka sig inåt i projektet för att visa beroenden mellan paket och till sist klasser. I vyn Similar Code visas klasser i projektet som innehåller liknande kod på ett överskådligt sätt med färgformatering för det som är lika och det som skiljer sig åt. Trycker man på knappen Perspective visas en helt tom tunn remsa vid sidan av knappen. Det är oklart hur det är tänkt att det ska funka och utifrån våra tester så fungerar inte knappen alls. Under Preferences kan man ställa in inställningar för de olika vyerna. Man kan där själv bestämma vilka av de 714 olika reglerna vektyget ska följa och hur allvarliga de är. Man kan bocka av varningar och metrics som man inte är intresserad av och bestämma hur beroenden ska skrivas ut och vilken färgformatering som ska användas i den grafiska bilden. Vektyget testar följande: Duplicerad kod Långa metoder För många beroenden mellan klasser (spaghettikod) Vi valde JDeodorant med följande motiveringar JDeodorant var det verktyg som uppfyllde flest av de krav vi hade på ett analysverktyg för code smells. Det var enkelt att använda, lätt att installerat som plugin till Eclipse och krävde ingen konfiguration. Det gav även utvecklarna förslag och kunde automatiskt implementera förslagen om utvecklaren önskade det. Nackdelarna är att det inte går att konfigurera. Den notifierar dessutom inte användaren om verktyget inte hittar några fel och det går inte att ignorera varningar som egentligen inte är fel och som utvecklaren inte vill ska dyka upp varje gång de testar koden. JDeodorant ger förslag på hur man kan skriva om koden så att den inte ska klaga på det nästa gång. Dock skulle vi gärna sett en funktion som gjorde att den inte behövde (kunde ignorera) klaga på en del av koden som inte gick att förbättra eller att verktyget gav ett felaktigt utslag på. Vi skulle gärna sett några inställningsmöjligheter, men i detta projektet klarar vi oss väldigt bra utan inställningsmöjligheter.

9 CodePro har väldigt många bra vyer som illustrerar källkodens uppbyggnad, dock är det ganska komplext och blir väldigt rörigt om man inte har tid för någon typ av utbildning eller hjälp med att få det att fungera för sitt projekt. Det har även väldigt många regler som man kan ändra och välja hur känsliga varje regel ska vara, det är en väldigt bra funktion men blir onödig komplext i vårt lilla projekt. En annan faktor som gjorde att vi inte valde CodePro var att enligt D Jönsson [ 6 ], så har Code Pro väldigt få analyser av konkreta code smells. PMD är väldigt omfattande verktyg och det är just därför det inte lämpar sig för detta projeket. Det är viktigt att det är enkelt att använda och konfigurera men PMD blir som sagt för komplext på grund av dess mängd funktioner som vi inte har användning för i vårt projekt. Verktyget skulle säkert vara väldigt bra vid ett större och längre projekt, där utvecklarna har mer tid att sätta sig in i programmet. 4.4 Test coverage Det finns mycket man kan få ut av att analysera tester [4], vi tycker följande är viktigt: Att kunna se hur stor del av koden som är testad Att kunna se vilka delar av koden som är testad och inte testad Att testfallen täcker in alla möjliga grenar i en metod Många av utvecklarna i projektet arbetar enligt XP för första gången, och har därav ingen tidigare erfarenhet att skriva testfall till källkoden. Analysverktyg för test coverage underlättar för utvecklarna att se om koden testas och att alla möjliga utfall är testade. Det finns tre olika sätt att analysera koden på [5] : Byte code instrumentation (lägger in testinstruktioner i byte koden under exekvering) Offline byte code instrumentation (lägger in testinstruktioner i byte koden efter kompileringen) Source code instrumentation (lägger in testinstruktioner i källkoden innan kompilering) I denna rapport har vi valt att inte lägga vidare fokus på dessa sätt att analysera kod på. Vi har istället valt att undersöka följande verktyg eftersom de är välkända och har stor marknadsandel. 4.5 Beskrivning av valda verktyg för test coverage JaCoCo (EclEmma) Verktyget är mer känt under namnet EclEmma men det är i själva verket namnet på utvecklingsteamet. Den senaste versionen använder Java Code Coverage Library och har gett EclEmma ett nytt namn JaCoCo. JaCoCo använder sig av byte code instrumentation.

10 Verktyget kan hittas och installeras genom Eclipse marketplace genom att man söker på antingen EclEmma eller JaCoCo. Verktyget är kostnadsfritt att använda. I menyraden dyker det upp en ny knapp med en röd grön rektangel och med en run pil i bakgrunden. För att köra JaCoCo markerar man en test fil eller ett projekt som innehåller en eller flera test filer och trycker på knappen. När testen är körda dyker det upp en ny tab i vyn med namn Coverage. I denna vyn ser man till en början test coverage för hela projektet men man kan klicka sig inåt i projektet för att visa en analys för paket, klasser och till sist metoder. I vyn Coverage kan man även utläsa hur många instruktioner som har exekverats, hur många som inte har exekverats och hur många instruktioner projektet har totalt. Det visar även för varje klass/paket/projekt ett procenttal på hur hur stor del av instruktionerna som har kört av de totala antalet. Verktyget är väldigt bra på att testa if else satser, det mäter nämligen hur många möjliga vägar det finns i en metod. Verktyget markerar koden röd om en del inte körs, gul om koden körs delvis (körs men inte genom alla möjliga grenar) och grön om alla möjlig fall testas. Har en metod ett värde större än 0% och mindre än 100%, så betyder det att metoden är delvis testad, ofta beror det på att alla möjliga fall i t.ex. en if sats inte är testade. Färgkodningen stannar kvar tills man börjar göra ändringar i filen. För att få tillbaks färgkodningen så får man köra programmet igen. Vektyget testar följande: Hur stor del av koden som är testad Att alla möjliga fall i en metod är testat Färgkodar källkoden om den är testad (grön), delvis testad (gul) och inte testad (röd) Atlassian Clover for Eclipse Clover finns inte i Eclipse marketplace men kan installeras genom att ange en viss URL till Eclipse som kan hittas på Clovers hemsida. Clover distribueras av ett företag och kräver licens, men kan kan prova det fritt i 30 dagar. Clover lägger sig som en ikon brevid den normala run pilen i Eclipse och denna trycker man på för att utvärdera koden. Clover använder sig av Source code instrumentation. När man startar Clover så dyker det upp i vyn, det första man ser är hur mycket av koden som körs i procent och även lika stor del är färgat grön på rektangeln (resten är rött) brevid procentsatsen. Man får även upp en liten ruta som visar hur många test som har körts, hur många som har lyckats, hur många paket/klasser som testats och mycket mer information. Den visar även komplexitet av koden brevid procentsatsen som är testat. Förutom denna vy kan man få upp många fler vyer och funktioner genom att klicka på den lilla panelen med massa konstigt utformade knappar som man ser uppe till höger i vyn. Vi undersökte inte alla dessa, då det var svårt att förstå vad knapparna visade och sedan var

11 programmet väldigt komplex och vi ville inte riskera stänga av någon regel. Vi hittade ett filter som kunde filtrera ut olika typer av fel och det var väldigt användbart då man fick stora mängder av fel i Clover. En funktion som gjorde oss förvirrade var funktionen Test contributions, där det plötsligt försvann saker och sedan poppade de upp igen utan att man gjorde något med datorn/verktyget. Man skulle behöva mycket tid för att sätt in sig och förstå alla funktioner och kunna använda programmet fullt ut. Programmet visar hur många av testfallen som har gått igenom, likt det man får ut från JUnit. Men en bättre funktion som Clover hade var ett Dashboard där man kunde få en väldig bra översikt av projeket. Clover kollar också så att testerna har gått igenom alla möjliga grenar, skulle det inte ha skett så rapporterar programmet detta, men färgar även källkoden gul istället för grön som betyder delvis testad respektive fullt testad och skulle koden inte alls testas så färgas den röd. När vi provade programmet så orsakade det oss stora problem. Efter att vi hade kört programmet med JaCoCO så provade vi med Clover och den visade ca 1000 fler instruktioner än JaCoCo (som då hade 4000 instruktioner). Vi provade sedan JaCoCo igen och då hade det plötsligt instruktioner och efter en omstart av Eclipse hade det sjunkit till instruktioner. Först efter vi kastat vårt repo och avinstallerat Clover och hämtat ut repot igen så hade JaCoCo 4000 instruktioner igen. Troligtvis uppstår problemet när Clover lägger in sina testinstruktioner innan kompilering ( source code instrumentation ) vilket generarar felaktiga analyser för JaCoCo som använder sig av On the fly byte code instrumentation. Vektyget testar följande: Hur stor del av koden som är testad Att alla möjliga fall i en metod är testat Färgkodar källkoden om den är testad (grön), delvis testad (gul) och inte testad (röd) Optimerar tester CodePro Analytix CodePro har även stöd för analys av test coverage som använder sig av byte code instrumentation. Som förklarats ovan (under rubriken Code smells) så visas en ny knapp i menyn vid namn CodePro efter installation. Under knappen View som då visas kan man välja Code Coverage. Denna vyn är till för att man ska kunna visa projektets code coverage, dock finns ingen knapp där man kan lägga till vilket projekt som ska analyseras. För att undersöka code coverage ska man istället kunna högerklicka på en main klass för att sedan där välja CodePro tools Run Code Coverage. När vi gör detta misslyckas analysen och flera exceptions visas i vyn. Utifrån våra undersökningar fungerar därför inte code coverage i CodePro Analytix i den utvecklingsmiljö vi hade tillgång till.

12 CodePro kan även automatiskt generera test. Detta är dock inget vi är intresserade av i detta projekt och vi har därför valt att inte undersöka detta djupare. En stor del av projektet är att de studerande ska bli bättre på att programmera och skriva test. En annan funktion som CodePro även har är att man automatiskt kan generera rapporter på hur projektets code coverage ser ut. Rapporterna kan genereras som HTML, text eller XML. Vektyget testar (ska testa) följande: Hur stor del av koden som är testad Historik för gammal test coverage Färgkodar källkoden om den är testad (grön), delvis testad (gul) och inte testad (röd) Vi valde JaCoCo med följande motiveringar JaCoCo är enkelt att installera, verktygets fyra olika analysmetoder är uppdelade i fyra olika flikar och blir således enkelt att överskåda. Förutom att Clover gjorde så att JaCoCo betedde sig konstig även när de inte kördes parallellt blev snabbt en avgörande faktor att inte välja det verktyget. Men Clover kräver även licens och det kostar, vilket vi inte hade någon budget för i detta projektet. Vi hade problem med att få Code Pro att fungera ordentligt och det gjorde att vi själva inte kunde analysera programmet tillräckligt egentligen. Dock måste verktyget fungera på de datorer vi ska använda och när de inte gjorde det så uteslöt vi det verktyget. D et är dock fullt möjligt att verktyget fungerar bättre på någon annan version eller operativsystem. 5 Resultat Test coverage under projektets gång (analyserat med JaCoCo) : Resultat efter första labben 64% (1139 av 1781 instruktioner var testade) Då vi inte hade GUI tester fick vi relativt låg test coverage. Vi lät därför två personer göra en spike på GUI testning till iteration 2. Resultat efter andra labben 85,6% (3421 av 3984 instruktioner var testade) GUI testning höjde resultatet ordentligt och det skrevs även mer testfall under denna iteration. Vi provade att köra Test Driven Development (TDD) denna gången, vilket vi uppmanade att följa i kommande iterationer.

13 Resultat efter tredje labben 86,9% (4980 av 5731 instruktioner var testade) I slutet av iterationen gav vi de utvecklare som var klara med sina stories i uppgift att skriva testfall och öka projektets test coverage. Resultat efter fjärde labben 89,6% (6264 av 6989 instruktioner var testade) Till denna iteration hade vi en spike som gick ut på att skriva testfall som även testade grenar i try catch satser vilket inte kördes tidigare. Detta höjde projektets test coverage ett par procent. Teamet hade stora problem med beroende på varvlopp som inte blev klart. Resultat efter femte labben 84,8% (6733 av 7944 instruktioner var testade) En i teamet var sjuk och teamet lyckades bara producera 3 av 7 estimerade story points. Teamet gjorde även en stor refaktorisering denna iteration som de tyckte underlättade den framtida utvecklingen. Resultat efter sjätte labben 74,8 % (6507 av 8694 instruktioner var testade) Eftersom detta var den sista iterationen fokuserade de på att bli klara med stories och hade inte lika stort fokus på att skriva test. Hur utvecklarna upplevde de två valda verktygen: Svar enligt den utskickade enkäten efter sista iterationen finns i Appendix A. 6 Diskussion Vi valde det två analysverktygen JaCoCo och JDeodorant främst eftersom då de är enkla att installera, snabba att köra och lätta att använda. Dessa faktorer ansåg vi vara mycket viktiga i vårt projekt då det har relativt kort livlängd och utvecklarna har ingen tidigare erfarenhet från liknande utveckling. I ett större projekt där man kan lägga mer tid på konfiguration och inlärning av verktyg skulle nog andra av de undersökta verktygen kunna vara användbara. Särskilt i början under projektet hade vi lite koll på teamets kanban board. Innan de flyttade över en story från implementing till done frågade vi alltid om de verkligen hade kört JDeodorant och JaCoCo. Flera gånger fick de då låta storyn stå kvar under implementing och gå tillbaks till sina datorer. Innan de var tillbaks igen och på riktigt kunde flytta över storien till done tog ofta bara fem till tio minuter men någon gång tog det upp till över en timme. Vi vet inte exakt vad det paret då åtgärdade men de hittade förmodligen mycket otestad kod och en del bad smells som skulle kunnat komma ut till den färdiga programvaran om vi inte använt oss av de två analysverktygen som vårt team använde oss av.

14 När vi såg det låga test coverage resultatet på 64% efter långlabb 1, så analyserade vi vilken del av koden som var testad och vilken del som var mindre testad. De klasser som var sämst testat procentuellt var GUI klasserna, därav planerade vi in en GUI test spike för två personer till långlabb 2 och då blev resultatet 85.9%, vi tryckte även denna gången mer på tester och när gruppen som utvecklade i samma rum berättade att de hade 95% test coverage så blev vår grupp mer sporrade att skriva fler testfall. På slutet av iteration 3 hade ett par inget att göra då det inte fanns fler stories som kunde påbörjas. Vi lät dem då skriva testfall för att kunna öka vår test coverage ytterligare. Med hjälp av JaCoCo kunde utvecklarna se vilka klasser som hade lägst test coverage och fokuserade på att öka test coverage för den koden. Fjärde långlabben märkte vi att utvecklarna inte hade riktigt samma ambition som tidigare och fick inte riktigt lika mycket gjort som de föregående iterationerna. Vi tog upp detta på följande planeringsmöte och det visade sig bero på att systemets design var väldigt stel vilket gjorde det svårt att lägga till annan funktionalitet. En orsak var även att många stories som skulle implementeras berodde på en annan specifik story som tog mycket längre tid än estimerat. Under femte långlabben gjorde teamet en stor refaktorisering i en sido branch som sedan integrerades till huvud branchen, för att underlätta framtid utveckling. Refaktoriseringen gjordes inte som en story, utan var tänkt att fixas snabbt då fyra utvecklare hade det som refaktoriserings spike till långlabben. Sjätte långlabben var sista iterationen och team fokuserade på att skriva klart så många stories som möjligt och hade mindre fokus på att skriva tester. De visste dessutom att de inte skulle arbeta vidare på projektet efter denna iterationen, så de prioriterade inte att skriva tester. När teamet var tvungna att utföra dessa större refaktoriseringar visade sig vår relativt höga test coverage vara hjälpsam. Om någon råkade ändra i koden som gjorde att den uppförde sig annorlunda visades sig detta direkt i testerna. Under projektets gång har vi hela tiden försökt hålla så hög test coverage som möjligt på systemet. Något vi också förklarat för teamet är dock att det även ska vara hög kvalité på testerna. Kämpar man endast för att få så hög test coverage som möjligt finns risken att man skriver dåliga tester som i själva verket inte testar något utan bara låter koden köras. Så i slutändan är det inte vilken procentsats test coverage man har som är viktig, utan testerna ska fungera som ett hjälpmedel för att kunna utveckla en så bra och stabil programvara som möjligt.

15 Vår förhoppning var att systemet inte skulle innehålla för många olika grenar. Det är bra att man kollar att man får in rätt värde, men det blir till en dyr kostnad. Det är viktigare att man skriver bra kod och man bör försöka undvika if satser som endast kollar att värdet är rätt i t.ex. input till GUI. Utvecklarna var ombedda att köra JDeodorant och JaCoCo efter de hade implementerat klart en story för att undvika bad smells och ha högt test coverage. Dock ser vi i vår enkät att långt ifrån alla använde verktygen efter varje story, det är främst JDeodorant som utvecklarna tycker fungerar dåligt och ger dåliga förslag. JaCoCo var utvecklarna mer nöjda med och den hjälper bara till att visa vilken kod som är testad och vad som har missats och har använts i större utsträckning. Man får ett konkret resultat av JaCoCo som är lättare att mäta jämfört med JDeodorants förslag och kvalitén den anmärker på. Vi hade som sagt målsättning att ha minst 90% i test coverage. Av enkätresultaten tyckte utvecklarna att det var en rätt rimligt målsättning. Dock så ser vi att vi aldrig nådde upp till 90% i slutet av några långlabbar, men dock stundtals under långlabbarna. Under felkällor diskuterar vi det resultatet närmare. Om man kollar på resultatet från enkäterna om hur utvecklarna upplevde att använda JDeodorant och JaCoCo (se Appendix A) så var de neutralt inställda till JDeodorant och överlag positiva till JaCoCo. Så verktyget JDeodorant fungerade tillfredsställande, men var inte till någon större hjälp. JaCoCo var mer lättanvänt och utvecklarna kände också att det bidrog mer till deras arbete. När vi diskuterade med utvecklarna om JDeodorant så uttryckte de att JDeodorant var kryptiskt, utskrifterna hade ingen relevant information, klagar på skumma saker, klagade på lite för mycket som som inte behövde användas och någon trodde att det skulle vara mer användabart om man hade större ambitioner. Utvecklarna tyckte att JaCoCo var intuitivt med färgning av koden i den utsträckning den testas, skönt att den kollade vad som testades så att man slapp hålla koll på det själv, bra med GUI som visar hur stor del av klasser och metoder som testades och dåligt att den inte tog hänsyn till catch i exceptions. Från resultaten från vår enkätundersökning så ser vi att nästan alla utvecklare tror att de kommer använda sig utav JaCoCo i framtida projekt, medans nästan ingen utvecklare tror att de kommer använda sig av JDeodorant i framtida projekt.

16 6.1 Felkällor Eftersom inte alla i teamet följer TDD till fullo så är en story inte helt testar förrän den verkligen är done done. Våra mätningar av test coverage som utfördes efter varje iteration kan därför vara lite missvisande eftersom att en del stories i forfarande låg under implementing. Dessutom beräknas test coverage även av testfilerna vilket kanske egentligen är ointressant och missvisande. 7 Slutsats JaCoCo fungerade bra för våra utvecklare och utvecklarna kände att de hade stor nytta av den höga test coverage när de refaktoriserade koden. Så valet av JaCoCo för våra utvecklare verkar har varit ett bra val och de uttryckte att de var tillräckligt och inte för komplext för detta projektet. JDeodorant fungerade okej, dock uttryckte utvecklarna att de klagade lite för mycket på onödiga delar av koden och att den inte gav någon bra förklaring. De andra programmen vi valde mellan gav många fler utslag och var mer komplexa och det hade nog passat utvecklarna sämre i detta projekt. Vi tror inte att man ska utesluta ett verktyg för bad smells som JDeodorant på liknande projekt, men vi tror att man skulle kunna köra verktyget mindre ofta och det hade varit fördelaktigt om man kunde ignorera fel som verktyget anmärkte på som inte var fel enligt utvecklarna. Det är svårt att dra större slutsatser hur väl verktygen har påverkat teamets framgångar, vi skulle behöva flera kontrollgrupper som utvecklar utan verktygen och med samma förutsättningar som vårt team. De andra team vi jämförde vårt resultat mot (inte presenterat i denna rapporten), bedrev egna djupstudier och de påverkade troligtvis deras resultat och därför kan vi inte jämföra resultaten mot varandra.

17 8 Källförteckning 8.1 Referenser [1] Francesca Arcelli, Fontanaa Pietro, Braionea Marco, ZanoniaAutomatic Detection of bad smells in code: An experimental assessment [2] Olivier Gaudin Bridging Internal and External Software Quality with Sonar and JaCoCo sonar jacoco [3] Usman Mansoor, Marouane Kessentini, Slim Bechikh, Kalyanmoy Deb Code Smells Detection using Good and Bad Software Design Examples [ 4] Sneha Shelke, Sangeeta Nagpure The Study of Various Code Coverage Tools 1/IJCTT V13P110.pdf [5] Qian Yang, J. Jenny Li, David M. Weissa A Survey of Coverage Based Testing Tools [6] David Jönsson Detecting code smells in educational software Källor JDeodorant PMD CodePro dev tools/codepro/doc/ JaCoCo Stephen H. Edwards and Zalia Shams Comparing Test Quality Measures for Assessing Student Written Tests

18 A. M. R. Vincenzi, W. E. Wong, M. E. Delamaro, J. C. Maldonado JaBUTi: A Coverage Analysis Tool for Java Programs et al 2003.pdf Brittany Johnson Novice Understanding of Program Analysis Tool Notifications Emil Einarsson Analysverktyg för kod och test Peter Seimar Verktyg för statisk kodanalys

19 9 Appendix A

20

21

22