Andreas Borg 1(10) Laboration 1 Inledning och förberedelser Det finns en uppsjö av teststrategier och testverktyg och i den här laborationen får du pröva några av dem: Enhetstest med JUnit GUI-testning med Abbot Täckningsmätningar med djunit Dessa verktyg utvecklas och kommer i nya versioner med jämna mellanrum men för att få dem att fungera med varandra, med Eclipse och på den givna koden i Laboration 2 använder vi inte alltid de senaste versionerna i labbserien. Det tydligaste exemplet är JUnit, som från och med version 4 har en delvis ny notation (som kräver Java 5.0) som inte används i kursen. För att läsa om nyheterna i JUnit4 rekommenderas t.ex. JUnit 4.0 in 10 minutes som finns på http://www.junit.org/news/index.htm. Laborationen omfattar tre olika delar: 1. Triangle. En klass som används för att avgöra om en triangel är oregelbunden, likbent eller liksidig. 2. Formatter. En klass som erbjuder stöd för att centrera respektive högerställa text. 3. Converter. Ett grafiskt gränssnitt för att konvertera temperaturer från Celsius till Fahrenheit. Den givna koden för respektive deluppgift hittar du under lab1/src i Package Explorer. Man bör alltid separera testfiler från produktionskod och därför ska du skapa en katalog test på samma nivå och med samma paketstruktur som den redan existerande src-katalogen. 1. Högerklicka på lab1 i Package Explorer och välj New->Source Folder. Ange lab1 som Project name och test som Folder name och klicka Finish. 2. Högerklicka på den just skapade test-katalogen och välj New->Package. Ange lab1/test som Source Folder och triangle som Name och klicka Finish. Upprepa steg 2 för att skapa även paketen format och converter. Deluppgift 1: TriangleProgram Målet med den första deluppgiften är att konstruera vettiga testfall för Triangle-klassen på ett sådant sätt att alla rader av koden i programmet körs. Testfallen ska köras i djunit, en utökning av JUnit som kan användas för att mäta täckningsgrad.
Andreas Borg 2(10) Som du minns har triangelexemplet redan förekommit på en föreläsning i kursen och för att lösa labbuppgiften kan det vara en god hjälp att erinra sig Myers 14 frågor som presenterades där. Öppna paketet src/triangle i Package Explorer i Eclipse. Där hittar du de båda klasserna TriangleProgram och TriangleType. TriangleProgram är ett program som givet en lista av sidlängder avgör vilken typ av triangel som bildas av sidorna (dvs. om den är oregelbunden, likbent eller liksidig). Din uppgift är nu att skriva testfall för klassen. För att skapa en testfil högerklickar du på TriangleProgram.java och väljer New-> JUnit Test Case. I dialogrutan som öppnas ska det nu stå Name: TriangleProgramTest. Ange lab1/test som Source folder och triangle som Package. Klicka på Next, kryssa därefter i metoden triangletype(int[])och klicka avslutningsvis på Finish. Nu har en testklass innehållande metoden testtriangletype skapats. I denna testklass ska du implementera testfallen för klassen TriangleProgram:s metod triangletype. Tips 1: För att avgöra huruvida en triangel är liksidig kan du t.ex. använda följade testfall: TriangleProgram tp = new TriangleProgram(); assertequals(triangletype.equilateral, tp.triangletype(new int[]{2,2,2})); Tips 2: Hur du testar ett förväntat undantag (Exception) finns beskrivet i en tidigare version av JUnit:s FAQ: http://www.cs.wm.edu/~noonan/junit/doc/faq/faq.htm#tests_7. Jämför gärna med JUnit 4.0-notation: http://junit.sourceforge.net/doc/faq/faq.htm#tests_6 Kör testfallen genom att högerklicka på TriangleProgramTest.java i Package Explorer och välj Run As->djUnit test. Utöver att klassens logik ska testas på ett tillfredsställande sätt ska både line coverage och branch coverage vara 100% för att deluppgiften ska betraktas som godkänd. Deluppgift 2: Formatter Deluppgift 2 innebär att skriva både kod och testfall för en enkel textformatterare. Under src/format i Package Explorer hittar du klassen Formatter som innehåller två metoder: public String rightstring(string text, int rowlength) public String centerstring(string text, int rowlength) Metoderna ska ta en text och en radlängd som argument och returnera en centrerad respektive högerställd textrad. I den givna koden returnerar båda metoderna tomma strängen och det är alltså din uppgift att skriva koden som centrerar respektive högerställer text. För att man ska se att texten har formatterats ska du fylla på med * istället för mellanslag.
Andreas Borg 3(10) Några exempel för centerstring: centerstring("hej", 5) => "*hej*" centerstring("hej", 6) => "*hej**" centerstring("hej", 7) => "**hej**" Om radlängden är kortare än texten ska bara mitten av ordet synas. Några exempel: centerstring("halloj", 2) => "ll" centerstring("halloj!", 2) => "ll" centerstring("halloj!", 3) => "llo" Några exempel för rightstring: rightstring("hej", 5) => "**hej" rightstring("halloj", 3) => "loj" Programmet körs genom att att högerklicka på Formatter.java i Package Explorer och välj Run As->Java Application, och därmed måste du även skapa en main-metod som startar programmet. Testfallen skapar du i FormatterTest.java (som skapas på samma sätt som i deluppgift 1 och ska ligga i test/format) och du kör dem genom att högerklicka på FormatterTest.java i Package Explorer och välja Run As-> JUnitTest. För att deluppgiften ska betraktas som godkänd ska formatteraren fungera enligt exempel ovan och alla tesfall som är nödvändiga för att testa funktionaliteten ska vara konstruerade. Både line coverage och branch coverage ska vara 100%. Deluppgift 3: Converter I paketet src/converter finns en grafisk applikation som omvandlar temperaturer från Celsius till Fahrenheit. Starta programmet genom att högerklicka på CelsiusConverter.java i Package Explorer och välj Run As->Java Application. Mata in en temperatur, t.ex. 20, och tryck Convert. Detta ger resultatet 68ºF. Pröva nu att mata in 30ºC och tryck Return. Temperaturen kommer att omvandlas till 86ºF. I klassen CelsiusConverterTest.java finns det testfall för att testa applikationen med hjälp av GUI-testverktyget Abbot. Eftersom vi redan har konstaterat att testfall ska separeras från produktionskod ska du börja med att dra testfilen från src/converter till test/converter i Package Explorer. Klicka OK i dialogrutan som visas på skärmen och kör sedan testfallen som djunit-test. Det visar sig att den totala täckningsgraden (overall coverage) är 85% line coverage. En känd bugg är att omvandlaren accepterar temperaturer under absoluta nollpunkten. Lägg till både testfall och den kod som behövs för att rätta buggen. Om användaren matar
Andreas Borg 4(10) in en temperatur som är lägre än -273.15ºC ska det stå "NA" istället för en temperatur i Celsius respektive Fahrenheit. De befintliga testerna omfattar endast de fall där man klickar på Convert-knappen. Skriv testfall för att kontrollera att det även fungerar att trycka Return när man matat in temperaturen. Tips: Använd metoden actionactionmap (leta i Abbot:s API, http://abbot.sourceforge.net/doc/api/) och skicka "notify-field-accept" till inmatningsfältet. För att få godkänt på deluppgiften ska den vara löst enligt ovan och du ska även ha nått en overall line coverage på 95% och overall branch coverage på 100%. Mer specifikt kan sägas att täckningsgraden ska vara 100% överallt utom line coverage för CelsiusConverter (96%) och CelsiusConverterString (75%). Redovisning Hela Laboration 1 redovisas genom att all kod och alla testfall som skrivits lämnas in. För deluppgift 3 gäller att du lämnar in de filer som du har ändrat eller lagt till kod i med dessa ändringar/tillägg markerade. Dessutom ska en kort diskussion (1-2 sidor) om de olika testmetodernas (enhetstest, GUI-test, mätning av täckningsgrad) möjligheter och begränsningar lämnas in. När är de lämpliga att använda och när är de mindre lämpliga? Angågende deluppgift 3 ska du svara på några frågor. Finns det någon rimlig anledning till varför de ursprungliga testfallen bara gav en täckningsgrad på 85%? Varför behövde inte täckningsgraden bli 100%? Hur tycker du att man bör hantera krav på full täckning i realistiska situationer?
Andreas Borg 5(10) Laboration 2 Inledning Syftet med Laboration 2 är att du ska få tillämpa principerna och verktygen från Laboration 1 på ett större program planeringsverktyget GanttProject (http://sourceforge.net/projects/ganttproject). Det består av ungefär 10000 rader kod och levereras vid nedladdning med 46 JUnit-tester. I testning ingår att förhindra att åtgärdade buggar kommer tillbaka vilket görs med så kallad regressionstestning. Att buggar kommer tillbaka är lätt hänt när man gör ändringar i stora system med många beroenden, och man vill alltså försäkra sig om att en rättad bugg inte återuppstår. Ett bra sätt är naturligtvis att behålla och köra de testfall som skapats sedan tidigare, men ofta upptäcks fel i gamla moduler som har ändrats. Varje gång ett sådant fel upptäcks bör ett nytt testfall skapas för att förhindra att buggen återuppstår. Vidare gäller att hur buggar upplevs och rapporteras ofta skiljer sig en hel del från den felsökning som måste göras och de tester som borde ha funnits. En utvecklare som får en buggrapport måste alltså först förstå vilket problem användaren har upplevt och vilken sekvens av händelser som ledde fram till situationen. Med den kunskapen delas arbetet upp i följande steg: 1. Återskapa felet. Felet återskapas för att verifiera att buggen finns. Går det inte att återskapa felet finns det risk att felet bara uppstår i vissa omgivningar såsom operativsystem, version på bibliotek och runtime-miljöer eller hårdvarukonfiguration. 2. Felsöka koden. Nu gäller det att hitta buggen eller buggarna som gör att felet uppstår, dvs. utföra debuggning. Det här steget är ofta svårt om felet uppstår på en hög abstraktionsnivå, t.ex. att något visualiseras fel i det grafiska gränssnittet. Att från den nivån hitta den eller de rader kod som är felaktiga kräver att man tar sig från systemnivå till enhetsnivå. 3. Åtgärda felaktigheter. Här rättas buggen eller buggarna. Utan god förståelse för designen av systemet finns stor risk att den förstörs vid buggrättningar. En bugg kan ofta rättas på många olika sätt men bara några få av dessa följer den tänkta designen när det gäller abstraktioner och beroenden mellan enheter i systemet. 4. Skapa testfall. Att en bugg har hittats av en slutanvändare tyder alltid på en brist i testningen. Uppenbarligen saknas testfall som påvisar det felet. Sist av allt ska man därför uppdatera sin testsvit med ett testfall som misslyckas för den gamla koden men lyckas för den nya, felrättade versionen. Förberedelser I labben kommer du att använda två äldre versioner av GanttProject. Dessa innehåller många buggar som är kända och rapporterade, och du ska få arbeta med tre av dem via både enhetstester och GUI-tester. De båda versioner av GanttProject som du kommer att arbeta med är: 1.10.3 1.11.1 pre release 3
Andreas Borg 6(10) För att köra GanttProject expanderar du önskad version i Package Explorer i Eclipse och navigerar fram till den fil som innehåller programmets mainmetod. Den nyare av de båda versionerna körs alltså på följande sätt: Ganttproject-1.11.1-pre3/src/net.sourceforge.ganttproject/ GanttProject.java Högerklicka på filen och välj Run As->Java Application. Ägna en liten stund åt att undersöka programmet (version 1.11.3 pre release 3) och sätta upp ett enkelt projekt så att du får en känsla för vad programmet gör och vilken terminologi som används. Du bör göra åtminstone följande: Skapa minst två användare som kan användas som resurser och tilldela dem roller på valfritt sätt. Skapa en ny uppgift som innehåller minst två deluppgifter. Undersök de olika alternativen som finns under Uppgiftsegenskaper (via menyval eller högerklick på uppgiften) och pröva att ange både uppgiftslängd, föregångare och personer som ska utföra uppgiften. Notera att man måste klicka på fältet under Uppgiftsnamn respektive Resursnamn för att få fram de alternativ man har. Deluppgift 1 Programversion: 1.10.3 Det rapporterade problemet som denna uppgift handlar om gäller ihopkoppling av aktiviteter/uppgifter. Ett exempel på buggen illustreras med filen end-end.gan som finns under menyvalet Laborationer på kurshemsidan. Följ den ovan beskrivna processen genom att först försöka förstå det upplevda problemet, och återskapa därefter buggen genom att öppna end-end.gan i GanttProject och jämföra valda Uppgiftsegenskaper med den grafiska visualiseringen. Därefter är uppgiften att felsöka koden, rätta buggen och skapa testfall som gör att den inte kan återuppstå. BUG: End-end relations cause problems You may monitor this Tracker item after you login (register an account, if you do not already have one) Submitted By: Date Submitted: Marc De Caluw 頭 marcdc 2005-02-03 06:59 Changed to Closed status by: Closed as of: dbarashev 2005-02-27 15:34 Last Updated By: Date Last Updated: dbarashev - Settings changed 2005-02-27 15:34 Number of Comments: Number of Attachments: 3 0 Category: (?) Group: (?) Relationship None
Andreas Borg 7(10) Assigned To: (?) Dmitry Barashev Status: (?) Closed Summary: (?) end-end relations cause problems Hi, Priority: (?) 7 Resolution: (?) Fixed When I use end-end relationships between tasks, the project behaves very strangely. In the xml-file the end-end relations are systematically saved as end-start relations, which may be the cause of the problems. If I manually change these realtions from type 2 to type 3 in the xml files, everything seemqs to work fine until the next time I save the project: all end-end relations are saved again as end-start relations and problems again. Regards, Marc Deluppgift 2 Programversion: 1.10.3 Denna deluppgift är den största och mest krävande i labbserien, trots att det inte ingår i uppgiften att rätta buggen. Fokus ligger i stället på att verkligen förstå upplevda och kringliggande problem och skapa testfall som fångar buggen. Det kan diskuteras om buggrapporten nedan beskriver en regelrätt bugg. Klart är i alla fall att det går att konstruera testfall för att se till att hänsyn tas till helger och det är nu din uppgift att göra det. Testklassen TestResourceAssignments.java (som du hittar under test/net.sourceforge.ganttproject.test.task) kan ge lite inledande tips till hur testfallen kan skrivas. När man skriver ett testfall och/eller rättar en bugg är det viktigt att även ställa sig frågan om den rapporterade buggen är en del av något större. I fallet GanttProject sätts och ändras längden på en uppgift på flera olika sätt (vilket skulle kunna sägas vara ett designproblem). Icke desto mindre måste du ta reda på vilka metoder som körs i det fall som användaren har upplevt ett fel och testa det. Du behöver alltså gå via metoderna för det grafiska gränssnittet och se hur de propagerar ner i programlogiken. Här är det lämpligt att använda de utmärkta funktionerna Open Call Hierachy, Open Type Hierachy och Open Declaration som finns i Eclipse för att leta i koden. Börja med att återskapa buggen i rätt programversion för att säkert förstå vad buggrapporten handlar om och övertyga dig själv om att du skriver ett testfall för just det
Andreas Borg 8(10) upplevda problemet. Dessutom måste du vara helt säker på att du testar rätt datum (verifiera t.ex. med enkla spårutskrifter) och måste därför undersöka hur GanttProject:s kalenderhantering är implementerad (inkl. arvsstruktur), läsa dokumentation och verifiera dina testfall. För godkänt på deluppgiften krävs att du skriver ett korrekt testfall för det upplevda problemet samt ytterligare testfall för minst ett av de alternativa sätten att sätta eller ändra uppgiftslängd. Men givetvis är det bäst att ha testfall för samtliga varianter. BUG: Tasks on week-end You may monitor this Tracker item after you login (register an account, if you do not already have one) Submitted By: Date Submitted: Pascal Bleser - pascalbleser 2003-07-09 02:04 Changed to Closed status by: Closed as of: nobody 2003-07-09 08:19 Last Updated By: Date Last Updated: pascalbleser - Comment added 2003-07-09 08:19 Number of Comments: Number of Attachments: 2 0 Category: (?) Group: (?) Gantt-chart 1.7 Assigned To: (?) Priority: (?) Nobody/Anonymous 7 Status: (?) Resolution: (?) Closed Later Summary: (?) Tasks on week-end Week-end days also count as workdays. If I create a task with e.g. 10 days effort, week-end days count, too. This must obviously be a bug ;-) Deluppgift 3 Programversion: 1.11.1 pre release 3 Detta är en intressant bugg av flera skäl: Dels finns det JUnit-tester för att undvika den uppkomna situationen och dels är den introducerad i den här versionen (den finns alltså inte i version 1.10.3 som vi har kört tidigare, pröva gärna!). Problemet illustreras tydligt på bilden nedan; den övergripande uppgiftens (supertask) uppfyllnadsgrad stämmer inte överens med ingående deluppgifters (nested tasks) uppfyllnadsgrad. Börja med att skapa ett projekt där buggen inträffar. Projektet ska heta supertask_bug.gan och sparas i din projektkatalog. Notera att du inte behöver göra projektet lika innehållsrikt som på bilden, men givetvis måste det finnas en supertask som har minst en nested task.
Andreas Borg 9(10) Anledningen till att buggen uppstår är att GUI:et inte är rätt implementerat, vilket innebär att GUI-testfall måste skapas för att detektera felet. Liksom i Laboration 1 använder vi Abbot för ändamålet och uppgiften är alltså att låta verktyget klicka sig fram till feltillståndet och indikera buggen. Kodskelett som ger dig inledningen på testfallet finns i test/idatestlabb/testtaskcompletionpercentagegui.java och de konstruktioner som finns där bör ge dig vägledning till hur du skapar resten av testfallet. Du har även nytta av att veta att veta följande: Den del av Öppna-fönstret som innehåller filnamn är en JFileChooser. De olika uppgifterna och deluppgifterna i GanttProject:s huvudfönster representeras med ett JTree. Egenskaperna för t.ex. en uppgift är en JPropertiesBean. BUG3: Supertask completion percentage is not updated correctly You may monitor this Tracker item after you login (register an account, if you do not already have one) Submitted By: Date Submitted: THOMAS Alexandre - bbadmin 2005-03-22 04:44 Changed to Closed status by: Closed as of: dbarashev 2005-04-10 03:07 Last Updated By: Date Last Updated: dbarashev - Settings changed 2005-04-10 03:07 Number of Comments: Number of Attachments: 1 1 Category: (?) Group: (?) Tasks devel Assigned To: (?) Priority: (?) Dmitry Barashev 7 Status: (?) Resolution: (?)
Andreas Borg 10(10) Closed Fixed Summary: (?) Supertask completion percentage is not updated correctly bug : report by david date : 20050322 explain : I'm using the prerelease and there is a little bug in the % settings. I explain : I've finished my first phase project, all the tasks are at 100% and in front of the main project there is 29%, but it should be 100% Also, we cannot see on the left the total display of the gantt, we cannot read the person and the % advancement. Also it can be a great idear to make a ladscape printing and think about a feature for printing long projects (1 to 2 years long) in one or several pages. Look at the picture for that. Redovisning Lämna in alla testfall samt den rättade koden från deluppgift 1 (markera vilka kodrader som har ändrats). Utöver programkoden ska du lämna in en rapport på 1-2 sidor. Gå in i GanttProjects buggdatabas genom att klicka på fliken Tracker och välja alternativet Bugs på http://sourceforge.net/projects/ganttproject. Ändra också Status till Any så att alla buggrapporter visas. Titta på ett antal rapporter och bilda dig en uppfattning om hur felbeskrivningarna verkar se ut i allmänhet. Är det någon skillnad på hur slutanvändare (eller kund) upplever ett fel och hur programmerare ser på det? Hur tycker du att buggrapporterna i laborationen fungerade i det hänseendet? Ange två buggrapporter du själv hittat som illustrerar ditt resonemang.