Avancerad användning av JUnit

Transkript

1 Avancerad användning av JUnit David Meyer, Adam Wamai Egesa D07, Lunds Tekniska Högskola 28 februari 2012 Abstract Denna djupstudie om avancerad använding av JUnit går närmare in på fyra avancerade användingsområden av JUnit, Mock Objects, exception testning, theories och parameterized testning. Dessa områden valdes efter granskring av flertalet artiklar som behandlade olika avancerade användningsområden för JUnit. Målet var att hitta bra avancerade användningsområden och verktyg för dessa samt att utvärdera dess användbarhet för oss själva och programmeringsprojekt i universitetskurser. Verktyg för alla områden utom Mock Objects och Theory Explorer i theories finns inbyggda i JUnit även om dokumentationen för vissa av dem var mycket bristfällig. För att generera Mock Objects användes verktyget Mockito[3]. Resultatet av studien blev fyra verktyg som kommer vara till nytta i framtiden för oss och eventuellt även för programmeringsprojekt i universitetskurser. 1 Introduktion 1.1 Bakgrund Denna rapport behandlar en djupstudie utförd i kursen Coaching för programvaruteam vid Lunds tekniska högskola (LTH) under läsperioderna /2012. Syftet med djupstudien är att utforska olika avancerade användningsområden för JUnit och undersöka dess relevans. JUnit används för att underlätta testning av Javaprogram. Genom ett ramverk av klasser för att skriva testfall gör JUnit att utvecklaren kan skriva testfall på ett bekvämare sätt och sedan köra alla tester på 1 av 19

2 en gång. Det finns en del i JUnit som heter Testrunner. Denna del tolkar testerna och utför själva testningen. Återkoppling för vilka tester som går igenom och vilka som fallerar ges sedan på ett bekvämt vis direkt i din IDE eller terminal. När ett testfall inte går igenom skrivs ett Failure Trace ut vilket ger detaljerad information om vad som gått fel och vart felet inträffat. 1.2 Syfte Valet av ämne beror på intresset att ta reda på om det finns avancerade testtekniker för JUnit som kan vara användbara i framtida projekt, både ute i arbetslivet och under studietid. I kursen ingår även ett projekt där vi agerar coacher för ett programvaruteam som skall ta fram programvara för ett tidtagningssystem. Teamet arbetar med Extreme Programming[17] där Test Driven Development (TDD) är ett viktigt inslag. Extreme programming är en agil utvecklingsmetod som kännetecknas av bla pair programming, continuous integration och Test Driven Development (TDD)[15]. Test driven development innebär att utvecklarna skriver testfallen före själva implementationen av programmet. Detta gör att själva designen av koden blir mer genomtänkt eftersom utvecklaren tvingas tänka igenom vad det egentligen är man vill uppnå. Det hade därför varit mycket tillfredsställande att finna verktyg och tekniker som kan hjälpa teamet i sitt arbete med TDD. Detta är ett ypperligt tillfälle att experimentera lite med avancerad användning av JUnit. Teamet som coachas består av programmerare som antagligen har mycket lite erfarenhet av testning. Därför är det viktigt att de verktyg som testas med teamet inte blir för avancerade och förstör istället för att hjälpa till. 1.3 Metod Metoden som används i denna djupstudie är att olika avancerade användningsområden för JUnit identifieras. Dessa användningsområdens relevans kommer sedan bedömas, främst genom en utvärdering av hur användbart vi själva bedömer att en viss mekanism är men vi kommer även att kolla på hur utbredd själva användningen är. Om det visar sig att ett verktyg eller en metod inte är något som används idag så betyder det antagligen att de inte är bra. För de användningsområden och verktyg som är relevanta kommer en referenssökning genomföras för att hitta säker information. Vissa mindre verktyg kanske inte behandlas i några vetenskapliga artiklar och tidskrifter. I sådana fall kommer information från utvecklare och community att användas. Efter att olika områden identifierats som relevanta kommer tester genom praktisk användning att genomföras. Detta är huvudsakligen tänkt att ske genom en enkel implementering. Därefter kommer en slutgiltig utvärdering att ske. Utvärderingen kommer gå in på relevans för användning i teamets arbete samt generell användning. 2 Användning av JUnit s standardmetoder Detta stycke syftar till att ge en snabb introduktion av JUnit för de läsare som inte är bekanta med verktyget. Om läsaren sedan tidigare använt JUnit kan denna del av uppsatsen hoppas över. För att kunna skriva testfall i JUnit behövs en import av org.junit.test;. Vanlig praxis är att göra en separat testklass för att testa en klass. En testmetod inleds med public 2 av 19

3 void testbankaccount(). I testmetoden skrivs sedan kod för att testa en viss del av originalkoden. För att ett testfall skall gå igenom eller misslyckas och för att TestRunner skall kunna ge en tydlig feedback används så kallade assert-metoder. Dessa metoder används för att definera hur utgången av ett lyckat testfall skall se ut. Den enklaste assert-metoden är asserttrue(boolean villkor). Om villkoret är sant kommer testet gå igenom, annars kastas ett AssertionError och ett felmeddelande skrivs ut med information om vilket assertion som misslyckts. Förutom asserttrue finns det också assertmetoder som assertnull(object obj) och assertarrayequals(int[] expecteds, int[] actuals). Ibland kan det vara användbart att anropa metoden fail(string felmeddelande), denna metod gör att ett AssertionError generars vilket leder till att testet direkt avbryts. Ett felmeddelande kan anges om så önskas. Enhetstester inleds vanligtvis med initiering av de objekt som används i det aktuella testfallet(fixtures), därefter görs anrop till assert-metoder för att kontrollera om de beter sig som det är tänkt. Istället för att initiera dessa objekt i varje testmetod kan en initieringsmetod skapas med Denna metod kommer då att anropas före varje testmetod och objekten kommer alltså initieras före varje test. Då det krävs någon form av städning efter varje testmetod kan även en metod med deklareras. Dessa två notationer kräver import av org.junit.before respektive org.junit.after. 3 Mock Objects och dess användning Själva idén med Enhetstestning är att testa varje del av koden för sig. Ett problem med att skriva enhetstester är att den del av koden som skall testas oftast använder objekt som ligger utom ramen för just den testade enheten. När andra objekt används i ett enhetstest så bygger alltså utgången av testningen på implementationen av dessa objekt. Om något objekt som används är buggat eller felaktigt implementerat kan det alltså resultera i att enhetstestet ger felaktigt resultat. Ett annat problem med beroende av yttre objekt är att testfall inte kan skrivas för än de objekt som skall användas i testet är implementerade. Detta kan leda till att programmerare som tillämpar Test Driven Development (TDD), tvingas frångå sina principer och skriva tester i efterhand eller vänta med att implementera just denna del av koden. I vissa fall är det till och med så att de objekt som behövs inte kan tilldelas de egenskaper som krävs i testmiljön med de publika metoder som finns.[2] Dessa problem kan lösas med hjälp av Mock Objects. Metoden går ut på att dummy Objekt skapas som ersätter de objekt man behöver vid själva enhetstestningen. Mock Objects kan alltså göra enhetstestet helt oberoende av andra delar av koden[2] vilket alltså kan vara till stor fördel. Mock Objects har många olika användningsområden där det kan förenkla testningen och lösa problem. Ett viktigt sådant område är program som använder sig av en speciell infrastruktur som är jobbig att sätta upp när testning sker. Det kan till exempel handla om en server eller en lokal databas. Ett Mock Object som härmar beteendet av en sådan infrastruktur kan skapas. Till exempel kan man då skicka meddelanden till Mock Objectet och få samma svar som om detta meddelande skickats till servern. 3 av 19

4 En annan aspekt av Mock Objects användning är att själva testerna tenderar att bli bättre då man med Mock Objects kan kontrollera värden mer frekvent genom att anropa JUnit metoden fail() då ett fel upptäcks. Detta gör att fel kan upptäckas snabbare och att ett mer specifikt felmeddelande kan genereras[2]. 3.1 Verktyg och praktisk användning Idag finns det verktyg som automatiskt kan generera MockObject för existerande klasser. Dessa verktyg är lätta att komma igång med och att använda. Det mest omtalade verktyget i denna kategori om man söker på internet är EasyMock. Det finns även ett lite nyare verktyg som heter Mockito.[3] Mockito är ett öppen källkod projekt under MIT License[4] vilket innebär att det är fritt att modifiera och använda. EasyMock och Mockito har mycket snarlik syntax och basen av mockitoutvecklare kommer ursprungligen från EasyMock. I denna djupstudie är det Mockito som vi har studerats lite närmare. För att komma igång med Mockito behövs bara en jar-fil som laddas ner på den officiella hemsidan och sedan länkas med ett Javaprojekt.[3] När detta är gjort krävs enbart en statisk import av org.mockito.mockito.*; i klassen där Mock Objects skall användas. Koden nedan visar hur ett Mock Object av klassen BankAccount skapas. BankAccounts -metod, public boolean insert(int sum), ställs in så att den alltid returnerar värdet public void TestInsert(){ BankAccount mockaccount=mock(bankaccount.class); when(mockaccount.insert()).thenreturn(true); asserttrue(mockaccount.insert()); Användingen av mockaccount Objektet i koden ovan visar enbart hur enkelt ett verktyg som Mockito är. Detta exempel visar inte på den styrka som själva användningen av Mock Objects är kapabelt till. Då Mockito visat sig vara mycket lättanvänt kommer det att testats på det team som coachas i kursen. 4 Testa Exceptions i JUnit Vanligtvis när enhetstester skrivs i JUnit används assertion metoder för att kontrollera om en metod beter sig så som det är tänkt. Till exempel kan ett test av en metod int sum(int a, int b) testas med hjälp av assertequal(a+b,sum(a,b)). När assert metoder används ges en tydlig feedback på vad som gått fel, vilka värden som förväntades och vilka värden resultatet gav. Exceptions kan testas genom användning av asserttrue(boolean b). Först defineras en boolean exceptionboolean och sedan skrivs den kod som skall testas inom en try catch sats. I catch blocket sätts exceptionboolean till true. Därefter körs asserttrue(exceptionboolean) för att kontrollera om ett exception har kastats eller inte. Detta sätt att testa exceptions var vanligt förekommande före junit 4 och Kent Beck beskriver denna metod i sin pocket guide för junit.[1] 4 av 19

5 I JUnit version 4 tillkom ett nytt sätt för att testa exceptions. Detta ger möjligheten att definiera en metod specifikt för att testa en viss typ av exceptions. Notationen är enligt följande exempel: import org.junit.test; import static public void numberformatexception() { String s="this is a string"; Integer.parseInt(s); Ett test går igenom om koden avbryts med det Exception som är angivet i (expected=). I detta exempel är det alltså NumberFormatException som förväntas vilket kastas då parseint() metoden inte lyckas konvertera strängen s till en Integer. Testet kommer alltså gå igenom. 5 I avsnitt 2 Användning av JUnits standardmetoder, diskuterades användning av för att definiera testmetoder vilka i sin tur innehåller själva testkoden. Det finns två andra sätt skriva tester med JUnit. Dessa två sätt använder sig av istället Båda metoderna kräver en ovanför klassdeklarationen där det anges om man vill använda sig av parameterized testning eller theories. Metoderna kan inte användas samtidigt i en testklass. För att reda ut exakt vilka begränsningar och funktioner som användning kunde innebära så producerades testkod. Denna testkod bearbetades och sammanställdes till exempelkod för denna uppsats. Koden finns under appendixen A.1 Theories exempelkod och A.2 Parameterized exempelkod. 5.1 Theories Bakgrund Theories är ursprungligen tänkt att användas som någon slags definition eller specifikation av ett givet beteende för en viss funktionalitet[13]. Detta kan jämföras med hur traditionella testfall vanligtvis endast testar ett fåtal scenarion [6]. Theories funktionaliteten skulle åstadkommas genom att analysera specifikationen. Med hjälp av denna analys skulle villkor sättas på den möjliga indatan till testmetoden. Villkoren skulle användas för att automatisk generera och sedan exekvera testet med alla möjliga 5 av 19

6 kombinationer av indata. Till en början var det tänkt att villkorsprogrammering 1 [16][8] skulle användas för att uppnå detta [6]. Givet att specifikationen är korrekt definierad så ger denna metod en bättre testning än vid traditionell testning eftersom programmeraren då riskerar att missa vissa viktiga kombinationer av indata [6]. Att använda theories är alltså tänkt att innebära användning av villkorsprogrammering för generering av indata samt att automatiskt kombinera och exekvera alla möjliga kombinationer av indata. Vilket alltså kan leda till att fler buggar hittas i koden snabbare. Implementationen i JUnit I JUnit har theories vidareutvecklats och producerat funktionaliteten bakom runnern Theory Metoder och variabler deklarerade definierar den indata som skall användas medan metoderna som är deklarerade tar in varje kombination som argument och testar dem. kan endast användas framför en publikt och statiskt deklarerad variabel eller metod. Skillnaden mellan dem är förväntar sig endast en variabel istället förväntar sig en array [9][10]. Där det kan noteras att tex list klasser som de skapade i Javas Collection hierarki endast räknas som objekt och inte som array. Generering av indata Till skillnad från den ursprungliga formuleringen om theories så ingår ingen villkorsprogrammering för att generera indata i JUnits implementation av theories. Däremot så är det möjligt att använda tex biblioteket Jacop för att utföra villkorsprogrammeringen nödvändig för att generera tänkt indata [8][16]. Det enda som krävs är att detta implementeras under Det går även att använda andra testmetodiker för att generera indata såsom Equivalence classes och Boundary value analysis beskrivet bl.a. i Implementationen av theories analyserar varje metod med och räknar ut alla möjliga kombinationer som indatan för varje metod kan anta utifrån det antal parametrar deklarerade för varje metod samt typerna för varje parameter. Varje möjlig kombination för en metod exekveras i egna instanser på samma sätt som metoder exekveras. Dvs att även metod exekveras före respektive efter varje anrop av en kombination för metod. Dessutom fungerar alla assert*-metoder, (se avsnitt 2 Användning av JUnits standardmetoder) på samma sätt som metoder. 1 Se avsnitt 6 Villkorsprogrammering för en utförligare förklaring om ämnet. 6 av 19

7 Avbrott med assume*-satser En av de främsta sakerna som skiljer exekveringen av metod från metod är hur de statiska assume*-metoderna i JUnit biblioteket såsom tex assumetrue(boolean b) fungerar. Där de i traditionella testfall fungerar precis som vanliga assertmetoder medan istället fungerar som ett filter. För det som händer när en assume*- metod exekveras i metod är att om en sats rapporteras inte stämma, dvs det som skulle motsvara ett rött testfall, så terminerar metoden sin exekvering av den givna kombinationen. Detta gör även att noggrannare analys kan producera villkor från assume*- metoder och sedan vidare automatiskt generera indata. Detta är dock inte någonting som ingår direkt i JUnit men det fristående verktyget Theory Explorer gör just detta[7]. I exempelkoden används detta för att inte utföra assert-satserna för strängar som inte har längden 8, vilket alltså utesluter en av variablerna som används som indata från att användas. Metodanrop för varje kombination Theories runnern kombinerar alltså alla möjliga variationer av den indata som definierats i samband och gör ett metodanrop för varje sådan kombination på metod. Antalet metodanrop som utförs på metod följer alltså som mest nedan beskrivna form: ( ) Då viss uteslutning sker när olika typer på parametrar används så kan dock antal metodanrop vara betydligt mindre. Detta kan tex observeras i exempelkoden där testsamedaywiththeory endast exekveras 16 gånger. Medan 125 exekveringar ges ifall alla typer istället anges till Object då implementeringen i så fall ej kan filtrera bort vissa resultat. Detta bekräftades via strategiskt placerade System.out.prints. Vidare så exekveras inte hela metoder vid de tillfällen då assume*-satserna inte går igenom och metoden terminerar tidigt. Det är även värt att nämna att används direkt vid deklareringen av en metod så fungerar inte den typ av filtrering av kombinationer innan exekvering Då författarna ej kunde få tillgång till dokumentationen så kunde de ej bekräfta vidare detta var en bugg eller en avsedd inkonsekvens i implementeringen. Som exempelkoden visar så är det dock möjligt att deklarera en statisk variabel och ta in data från en annan statisk metod och därmed bibehålla den huvudsakliga funktionaliteten. Försök att direkt utan att ändra deklararationen av parametertypen resulterar annars i ett java.lang.illegalargumentexception som kastas av Javas VM. I appendixet A.1 Theories exempelkod så observeras att metoden testsamedaywithtest testar motsvarande assert-satser som metoden 7 av 19

8 kommer att köra. Vilket visar på att theories implementationen betydligt förenklar läsbarheten och reducerar mängden kod som behöver skrivas. Exempel Följande deklaration som används i exempelkoden som syns i appendix A.1 Theories public static String[] sometimes = sometimes(); public static String[] sometimes() { return new String[] { " ", " ", " ", "-1" public static Integer adaynbr() { return new Integer(1); Som kan observeras så deklareras en String-array statiskt som sedan läser in resultatet från en annan statiskt deklarerad metod. Detta är främst gjort för att poängtera att även om runnern kan skicka in fel typer metoder (genom att med metoder som nämnts ovan) så kan detta undvikas genom att istället deklarera arrayer direkt i koden och sedan delegera värdet genom ett metodanrop, som i koden. Detta resulterar i exakt samma funktionalitet som skulle funnits om det inte funnits en bugg för metoder. Som även är synligt så returnerar en annan funktion ett Integer värde som alltså används för att sedan vidarebefodras till theory runnern som vidare använder alla andra variabler hämtade för att exekvera metoderna i exempelkoden Följande deklaration som används i exempelkoden som syns i appendix A.1 Theories public void testsamedaywiththeory(integer day, String timeinput1, String timeinput2) { assumetrue(timeinput1.length() == 8); assumetrue(timeinput2.length() == 8); MyTime mytime1 = new MyTime(day, timeinput1); MyTime mytime2 = new MyTime(day, timeinput2); asserttrue(mytime1.issameday(mytime2)); Givet att ovan har blivit inlästa sker alltså 16 metodanrop. Då det endast finns 1 variabel av typen Integer och totalt 4 variabler av typen String kombineras dessa 4 helt enkelt på alla möjliga sätt tillsammans med Integer variabeln. Det kan vidare ses att varje kombination som innehåller variabeln deklarerad som -1 i String arrayen inte kommer att passera en av assumetrue- 8 av 19

9 satserna då de kräver att båda String variabler har längden 8. Just denna filtrering har ingen egentlig mening utan är bara ett exempel på hur theories kan användas. asserttrue-satsen kommer vidare i detta exemplet alltid att vara sanna för alla variabler då samma dag används för båda objekten som jämförs. Deklarativa och konstruktiva theories Som även beskrivs i [14] så kan theories främst användas på två olika sätt. Detta är på ett deklarativt (eng. declarative) respektive konstruktivt (eng. constructive) sätt. Deklarativ användning av theories innebär att använda theories mer likt hur den ursprungligen tänktes användas, som ett sätt att skriva specifikationer. Där skall hålla för all möjlig indata, förutom den indata som inte håller för de angivna assume*-satserna. Varvid det främst menas att hela dimensionen av möjlig indata skall genereras automatiskt. Som nämnts kan det göras allmänt med någon form av villkorsprogrammering där ett exempel är det verktyg som utvecklats parallellt med theories, Theory Explorer. I vilket det valts att inte söka igenom alla möjliga lösningar utan istället försöka hitta en mer konsekvent hanterlig mängd indata som istället täcker en stor del av indatan som kan ge upphov till buggar. Vilket det i [14] vidare beskrivs ge upphov till att Theory Explorer kan skala bra vid användning i större projekt. Det andra sättet att använda theories på, det konstruerande sättet, är mer analogt med den traditionella scenariobaserade testning som annars används i JUnit. Varvid alla DataPoint(s) istället används som exempel på giltig indata för ett visst påstående. Ovan visad exempelkod är främst skriven på ett konstruerande sätt då endast en väldigt liten mängd indata används. Exempelkoden är dock samtidigt ett typexempel för theories som kan omvandlas, eller utvidgas till att skrivas på ett mer deklarativt sätt. Detta genom att autogenerera indata på tidigare beskrivet vis, via Theory Explorer eller liknande sätt. Eventuell användning av testmetodiker för att generera indata kan istället igen beskrivas som en konstruerande användning av theories. Jämförelse med exempelbaserad testning I [14] så observeras det att många utvecklare ofta tänker i form av specifikationer och inte bara i form av exempel som exempelbaserad testning annars bygger på. Där konstateras att omkring 25% av tester i de undersökta opensource projekten kunde direkt översättas till det mer generella, theories. Medan så mycket som 67% av de testfall som de som utvecklade theories naturligt kunde uttryckas i theories utan nämnvärd ökning i utvecklingskostnader. Det var i stor utsträckning även möjligt att skriva dessa theories på ett konstruktivt sätt. Det var därför vidare möjligt att använda deras verktyg Theory Explorer för att hitta indata som bröt mot den specifikation skrivits och därmed hitta buggar som annars kan förbises i exempelbaserad testning pga den mänskliga faktorn. 5.2 Parameterized Sammanfattning av funktionalitet Beteckningen parameterized beskriver funktionaliteten i JUnit. Funktionaliteten som parameterized tillför är att kunna köra konstruktorn före varje testfall och Vidare så körs konstruktorn och varje testfall en gång för varje Object-array som returneras av metoden. Vilket till viss del förklarar varför alla 9 av 19

10 @Parameters-annoterade metoder måste returnera Collection<Object[]>. Där alltså varje Object[] skickas in till konstrukturn före varje vanlig exekvering av testfallen. Mer specifikt så skickas varje element i Object-array:en in som argument i den ordning som de är lagda i array:en. Det objekt på index 0 i array:en skickas alltså som det första argumentet och det med index 1 som det andra metoder måste även deklareras statiskt och vara publika[5][11]. Utförligare förklaring av funktionalitet Efter alla importer inleds testklassen i exempelkoden som syns i avsnittet A.2 Parameterized exempelkod med public class TestingParameters Som tidigare nämnt gör detta att funktionaliteten används i klassen. Mer specifikt så medför denna deklaration att klassen org.junit.runners.parameterized körs istället för JUnits standard runner som annars används i JUnit. Deklarationen av klassen efterföljs av några få variabeldeklarationer och sedan de metoder som exekveras av parameterized public static Collection<Object[]> allformats() { ArrayList<Object[]> allformats = new ArrayList<Object[]>(); allformats.addall(somecorrectformats()); allformats.addall(someincorrectformats()); return public static Collection<Object[]> somecorrectformats() { return Arrays.asList(new Object[][] { { true, " ", { true, " ", { true, " " public static Collection<Object[]> someincorrectformats() { return Arrays.asList(new Object[][] { { false, "-1", { false, " ", { false, " " ); Utan en inblick av hur runnern fungerar så skulle det lätt gå att tro att den kommer att behandla alla metoder annoterade på samma vis. Detta är dock inte fallet. Endast den första metoden med annotationen används senare i programmet. Detta medför alltså att metoderna somecorrectformats och someincorrectformats endast används till allformats -metoden när den exekveras av runnern för parameterized och inte annars. Som i exemplet måste metod både vara statisk och publik, samt returnera en Collection av Objectarrayer. 10 av 19

11 Metodanrop Exemplet fortsätter på följande sätt (JavaDoc har public void setuptest() { System.out.println(" before method"); public TestingParameters(boolean iscorrectformat, String timeinput) { System.out.print("Constructor executed with values: [" + iscorrectformat + ", " + timeinput + "]"); this.timeinput = timeinput; this.hascorrectformat = public void testformats() { MyTime mytime = new MyTime(timeInput); assertequals(mytime.hascorrectformat(), hascorrectformat); Dessa metoddeklarationer medför att runnern kallar alla dessa metoder i ordningen TestingParameters(boolean iscorrectformat, String timeinput) (konstruktorn), setuptest (@Before), testformats (@Test) och om den funnits med. De körs alla i individuella instanser på samma annars körs av standard runnern. Vidare så exekveras konstruktorn och därmed hela kedja för varje element i den Collection som returneras från metoden annoterad och förhåller sig alltså på följande sätt: Då varje element i den Collection som används innehåller en Object-array så tar parameterized runnern alla elementen i den arrayen och lägger de som argument till varje konstruktoranrop. Där det första argumentet matchas till det första elementet i varje Object-array, andra argumentet till andra argumentet i varje Object-array etc. I exempelkoden används denna funktionalitet till att spara argumenten som privata variabler för att sedan användas i annoterade metoden. Utskrifter från exempelkoden Exekvering av testklassen genererar följande utskrifter: Constructor executed with values: [true, ] before method Constructor executed with values: [true, ] before method Constructor executed with values: [true, ] before method Constructor executed with values: [false, -1] before method Constructor executed with values: [false, ] before method Constructor executed with values: [false, ] before method 11 av 19

12 Endast metod räknas Som nämnts ovan så används endast den första metoden annoterad av parameterized runnern. Då endast en konstruktor kan deklareras i varje klass med en parameterized runner så används alltid alla variabler som deklarerats för en given testmetod. För mer varierande utdata måste därför extra argument som beskriver detta anges. I exempelkoden exemplifieras detta genom att två variationer på olika utdata förväntas från den givna indatan. Indatan förväntas mer konkret vara antingen i korrekt respektive inkorrekt format. I exempelkoden separeras detta i testmetoden genom att ett extra booleskt värde anges som argument som alltså anger om indatan förväntas vara i korrekt eller inkorrekt format. För att undvika detta extra argument för att skilja på vilken utdata som förväntas för ett test så är det också naturligtvis möjligt att göra en egen klass för all indata som genererar en förväntad utdata som kan testas. Vilket alltså tex hade delat in exempelkoden i två klasser. En som testade indata som genererar korrekta format och en som testade indata som generar inkorrekta format. 6 Villkorsprogrammering Kortfattat går det att konstatera att villkorsprogrammering (eller engelska constraint programming) används för att lösa olika kombinatoriska (optimerings) problem. Detta görs genom att modellera problemen med diverse villkor på variabler och därefter hitta lösningar som uppfyller dessa villkor. Att hitta dessa lösningar görs av en så kallad solver och kan separeras från språket det skrivs i. Ett exempel är att villkoren både kan skrivas i ett programmeringsspråk kallat MiniZinc och i java, där det i det senare fallet kan göras m.h.a. biblioteket som finns till Jacop[8][16]. Program som är skrivna med villkor kan sedan båda använda solvern Jacop[8][16] för att hitta lösningar som uppfyller ett givet kombinatoriskt problem. 7 Framåtblickar och diskussion Under denna djupstudie valde vi att gå närmare in på fyra områden. Mock Objects, Exception testning, theories och parameterized testning. Det finns direkt stöd i JUnit för alla dessa metoder förutom Mock Objects. För att autogenerera Mock Objects användes tredjeparts verktyget Mockito som visade sig vara mycket enkelt att komma igång med. Det fanns bra dokumentation på sidan för utveckling av Mockito. Värre var det med de inbyggda testfunktionerna theories och parameterized. Dokumentationen var mycket bristfällig och de kodexempel som hittades var inte så enkla att tolka direkt för att förstå exakt vilka begränsningar de led av. Detta berodde bland annat på saker som att asumethat() har en annorlunda funktion när theories används än vid traditionell testning. Att testa exceptions visade sig vara trivialt eftersom det finns ett inbyggt stöd för just detta sedan JUnit version 4. Till en början verkade theories och parameterized testning lite onödigt på grund av att det var lite svårare att sätta sig in i. Med facit i hand kan man dock konstatera att det är användbart för vissa tillämpningar. Parameterized är som bäst när ett värde på utdata håller för en godtyckligt stor mängd 12 av 19

13 indata. Och då varierad utdata, vid användning av parameterized, kräver ett extra argument för konstruktorn och därmed ett mer element för varje array som skickas in. Det kan i sådana fall genereras renare kod än traditionell testning utan att ta mera tid att utveckla, då det är mindre att skriva än traditionell testning. Konstruerande theories kan användas som exempelbaserad testning och kan analogt med parameterized då också producera enklare kod att läsa utan att ökade utvecklingskostnader. En konstruktiv theory kan emellertid användas som specifikationer på beteende i programmet. Det kan istället vara ett bra komplement för utvecklare de gånger det kan vara ännu naturligare att skriva test som specifikationer. Med verktyg som Theory Explorer är det sedan möjligt att automatiskt generera indata som skall täckas och utan extra utvecklingskostnader på det sättet hitta flera buggar. Då mänskliga faktorer kan leda till missade scenarion som inte testas i vanlig exempelbaserad testning. Anledningen till att vi valde just detta ämne var intresset av att hitta funktioner och verktyg för testning som vi senare skulle kunna använda i framtida skolprojekt och i arbetslivet. De verktyg som vi tittade närmare på verkar lovande för dessa ändamål och vi kommer med största sannolikhet att tillämpa det vi lärt oss. Ett annat mål med djupstudien var att undersöka om det fanns några avancerade användningsområden i JUnit som skulle kunna användas av det team vi coachar. Vi anser att det är lämpligt ta upp resultatet av denna studie med teamet och låta dem avgöra om det är något som känns användbart. För att kommunicera inom gruppen används en wiki sida. Denna sida skulle kunna fungera som ett lämpligt medium för att förmedla delar av djupstudien till gruppen, tex genom kodexempel och lite kort förklarande text. I vårt sökande efter bra avancerade användningsområden i JUnit stötte vi på många verktyg som inte länge uppdaterades eller verkade användas aktivt. Det finns dock några verktyg som ser lovande ut vars användbarhet inte hunnit undersökas inom tidsramen för detta projekt. Tre saker vi hade velat kollat ännu närmare på är Hamcrest, Categories och JUnitMax. Det hade även varit intressant att fördjupa sig ännu mer på theories området genom att testa och utvärdera Theory Explorer mer grundligt. Ytterligare experimenterande med kod hade också kunnat vara nyttigt då det är det bästa sättet att utvärdera hur användbart ett verktyg egentligen är. 7 Referenser [1] Kent Beck. JUnit Pocket Guide. O Reilly Media, Gravenstein Heigh North, Sebastopol, 2004 [2] Mackinnon, T., Freeman, S., Craig, P. Endotesting: Unit Testing with Mock Objects. In Extreme Programming Examined, G. Succi and M. Marchesi, Eds. The XP Series, pages Addison-Wesley Longman Publishing Co., Boston, MA, [3] Szczepan Faber and friends. Hämtad senast 26 februari [4] Hämtad senast 26 februari [5] Isa Goksu. using-junit-parameterized-annotation/. Hämtad senast 26 februari [6] D. Saff. Theory-infected: or how I learned to stop worrying and love universal quantification. In OOPSLA 07: Companion to the 22nd ACM SIGPLAN conference on Object oriented programming systems and applications companion, pages , New York, NY, USA, ACM. 13 av 19

14 [7] David Saff. From Developer s Head to Developer Tests Characterization, Theories, and Preventing One More Bug. In OOPSLA 07: Companion to the 22nd ACM SIGPLAN conference on Object oriented programming systems and applications companion, pages , New York, NY, USA, ACM. [8] Krzysztof Kuchcinski, Radosław Szymanek. Hämtad senast 26 februari [9] Hämtad senast 26 februari [10]Jacob Childress. Hämtad senast 26 februari 2012 [11] Hämtad senast 26 februari 2012 [12] Hämtad senast 26 februari 2012 [13] David Saff, Marat Boshernitsan. The Practice of Theories: Adding For-all Statements to There- Exists Tests. December 7, Hämtad senast 26 februari [14] Saff, D., Boshernitsan, M., Ernst, M.D. Theories in practice: Easy-to-write specifications that catch bugs. Technical Report MIT-CSAIL-TR , MIT Computer Science and Artificial Intelligence Laboratory, Cambridge, MA, January 14, [15] Kent Beck. Test-Driven Development: By Example. Addison-Wesley, Boston, [16] Krzysztof Kuchcinski. Constraints-Driven Scheduling and Resource Assignment. ACM Transactions on Design Automation of Electronic Systems, Vol. 8, No. 3, pages , July [17]K. Beck. Extreme Programming Explained: Embrace Change, Addison-Wesley, Boston, September av 19

15 A Exempelkod A.1 Theories exempelkod TestingTheories.java import static org.junit.assert.*; import static org.junit.assume.*; import org.junit.test; import org.junit.experimental.theories.datapoint; import org.junit.experimental.theories.datapoints; import org.junit.experimental.theories.theories; import org.junit.experimental.theories.theory; import org.junit.runner.runwith; import public class TestingTheories { * Times to be used method. * Times to be used public static String[] sometimes = sometimes(); * Method to statically determine the input times to be used. * The input to be used by methods. public static String[] sometimes() { return new String[] { " ", " ", " ", "-1" ; * Variable to be used public static Integer adaynbr() { return new Integer(1); * Asserts that two time objects with same day are considered to be on the * same day. * 15 av 19

16 day * The day to be used by both time objects. Should be sent in as * Integer. Declared as an Object parameter to avoid type * mismatch error from conversion from String to Integer. timeinput1 * Time to be used by first time object. timeinput2 * Time to be used by second time public void testsamedaywiththeory(integer day, String timeinput1, String timeinput2) { assumetrue(timeinput1.length() == 8); assumetrue(timeinput2.length() == 8); MyTime mytime1 = new MyTime(day, timeinput1); MyTime mytime2 = new MyTime(day, timeinput2); asserttrue(mytime1.issameday(mytime2)); * Asserts that two time objects with the same day are considered to be on * the same day. Does the same thing as method * public void testsamedaywithtest() { ArrayList<Object> inputs = new ArrayList<Object>(); inputs.add(adaynbr()); for (int i = 0; i < sometimes.length; i++) { inputs.add(sometimes[i]); MyTime mytime1, mytime2; String timeinput1, timeinput2; Integer daynbr; for (int i = 0; i < inputs.size(); i++) { for (int j = 0; j < inputs.size(); j++) { for (int k = 0; k < inputs.size(); k++) { timeinput1 = inputs.get(j).tostring(); timeinput2 = inputs.get(k).tostring(); if (!(timeinput1.length() == 8)!(timeInput2.length() == 8)!(inputs.get(i) instanceof Integer)) { continue; daynbr = (Integer) inputs.get(i); mytime1 = new MyTime(dayNbr, timeinput1); mytime2 = new MyTime(dayNbr, timeinput2); asserttrue(mytime1.issameday(mytime2)); 16 av 19

17 MyTime.java import java.util.regex.matcher; import java.util.regex.pattern; public class MyTime { protected int daynbr; protected String timeinput; protected Pattern timepattern; protected static final String REGEX_FORMAT = "(([0-1]?[0-9]) ([2][0-3])).[0-5]?[0-9].[0-5]?[0-9]"; public MyTime(int daynbr, String timeinput) { this.daynbr = daynbr; this.timeinput = timeinput; this.timepattern = Pattern.compile(REGEX_FORMAT); public MyTime(String timeinput) { this.daynbr = 0; this.timeinput = timeinput; this.timepattern = Pattern.compile(REGEX_FORMAT); * Checks if the timeinput value stored in this object has a correct time * format. A correct time format has the form "hh.mm.ss", clock starts at * " " and ends at " ". * Returns true if the timeinput value has the the correct time * format. public boolean hascorrectformat() { Matcher matcher = timepattern.matcher(timeinput); return matcher.matches(); * Compares another time object's day with own day, returns true if equal. * mytime2 * Another time object. boolean value from comparison between this object daynbr with * value from other time object. public boolean issameday(mytime mytime2) { return daynbr == mytime2.daynbr; 17 av 19

18 A.2 Parameterized exempelkod import static org.junit.assert.*; import java.util.arraylist; import java.util.arrays; import java.util.collection; import org.junit.before; import org.junit.test; import org.junit.runners.parameterized; import org.junit.runners.parameterized.parameters; import public class TestingParameters { protected String timeinput; protected boolean hascorrectformat; * List of Object arrays that are individually given as arguments to the * constructor before execution of method. * The list of Object arrays to be used as public static Collection<Object[]> allformats() { ArrayList<Object[]> allformats = new ArrayList<Object[]>(); allformats.addall(somecorrectformats()); allformats.addall(someincorrectformats()); return public static Collection<Object[]> somecorrectformats() { return Arrays.asList(new Object[][] { { true, " ", { true, " ", { true, " " public static Collection<Object[]> someincorrectformats() { return Arrays.asList(new Object[][] { { false, "-1", { false, " ", { false, " " public void setuptest() { System.out.println(" before method"); 18 av 19

19 * The constructor is executed for method for each Object * array returned by method. If there is a * * The constructor will be executed before method. * iscorrectformat * Index 0 of the Object array given by method. timeinput * Index 1 of the Object array given by method. public TestingParameters(boolean iscorrectformat, String timeinput) { System.out.print("Constructor executed with values: [" + iscorrectformat + ", " + timeinput + "]"); this.timeinput = timeinput; this.hascorrectformat = iscorrectformat; * Asserts that the the private String variable timeinput creates a MyTime * object with the correct format if the private boolean variable is true. * If false it is asserted that the MyTime object has an incorrect public void testformats() { MyTime mytime = new MyTime(timeInput); assertequals(mytime.hascorrectformat(), hascorrectformat); 19 av 19