Forelæsning Uge 10 Mandag

Transkript

1 Forelæsning Uge 10 Mandag Opremsningstyper Enumerated types Forskellige teknikker til test og debugging Når man tester undersøger man, om opførslen (semantikken) er den ønskede Når man debugger (afluser), forsøger man at finde ud af, hvorfor opførslen ikke er, som man ønskede og forventede Projektopgave om computerspil I kursets sidste fem uger skal I, sammen med en makker, programmere et computerspil Der er fem delafleveringer og de indgår tilsammen med ca. 30% i den endelige karakter for kurset

2 Opremsningstyper (enumerated types) Type, hvor brugeren eksplicit bestemmer de mulige værdier Nedenstående type har 8 mulige værdier Bemærk at værdierne ikke er tekststrenge Man bruger værdierne ved f.eks. at skrive Weekday.THURSDAY public enum Weekday { // A value for each weekday, // plus one for unrecognised commands. MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY, UNKNOWN 8 værdier Alternativet kunne man repræsentere ugedagene ved hjælp af heltal [1,7] eller ved hjælp af tekststrenge Heltal ville være sværere at forstå, og hvad betyder det, hvis man har en illegal værdi som 17 eller -3 Tekststrenge kan let indeholde stavefejl (f.eks. "Tusday") Det kan de selvfølgelig også, når vi bruger en enumereret type Men dem vil compileren fange 2

3 Mere komplekse enumerations Opremsningstyper kan også indeholde feltvariabler og metoder Man bruger stadig værdierne ved f.eks. at skrive Weekday.THURSDAY public enum Weekday { MONDAY("Monday"), TUESDAY("Tuesday"), WEDNESDAY("Wednesday"), THURSDAY("Thursday"), FRIDAY("Friday"), SATURDAY("Saturday"), SUNDAY("Sunday"), UNKNOWN("?"); private String weekday; Weekday(String weekday) { this.weekday = weekday; public String tostring() { return weekday; tostring metode returnerer værdien af feltvariablen weekday String repræsentation af ugedagen Feltvariabel af type String Konstruktør Opdaterer feltvariablen Konstruktører for enum typer er altid private Man kan ikke tilføje nye værdier 8 værdier (de har nu en tekststreng som parameter) Hvis man f.eks. vil ændre input/output til Tysk: Tekststrengene ændres til Montag, Dienstag, Mittwoch, Donnerstag,. Værdierne er uændrede: MONDAY, TUESDAY, WEDNESDAY,. 3

4 Eksempel på brug Erklæring af tre lokale variabler af typen Weekday Udskrift via hjælperutine public static void test() { Weekday day2 = Weekday.TUESDAY; Weekday day6 = Weekday.SATURDAY; Weekday dayx = Weekday.UNKNOWN; print(day2); print(day6); print(dayx); private static void print(weekday day) { String daystring; Lokal String variabel switch( day) { case MONDAY: case TUESDAY: case WEDNESDAY: case THURSDAY: case FRIDAY: daystring = " is a workday"; break; case SATURDAY: case SUNDAY: daystring = " is a day off"; break; default: daystring = " is an invalid day"; break; System.out.println( day + daystring ); Switch sætning (med variabel fra opremsningstype) Værdi fra Weekday typen (tostring metoden i Weekday) Tekststreng fra switch sætning 4

5 Unit tests Test af en afgrænset programenhed, f. eks. Klasse Metode Unit tests kan f.eks. foretages ved hjælp af BlueJ's inspektorer Viser værdien af feltvariabler (og klassevariabler) 5

6 Positive og negative tests Et positivt test undersøger om programenheden opfører sig som forventet Bliver en persons navn opdateret til den tekststreng, som vi angiver i kaldet af setname metoden? Et negativt test undersøger om programenheden opfører sig fornuftigt i fejlsituationer Hvad sker der, hvis vi forsøger at sætte navnet til den tomme streng eller alderen til noget negativt eller meget stort? Begge typer tests er vigtige Man er ofte tilbøjelig til at glemme (eller nedprioritere) de negative tests Lad være med det 6

7 Regressions tests (automatiske tests) Regressions tests (regression tilbageslag / forværring) Når man ændrer i en klasse, bør man efterfølgende tjekke, at alting stadig fungerer korrekt (dvs. opfylder passende positive og negative tests) Har man ved et uheld fået ødelagt noget, som tidligere fungerede? Det er tidskrævende og kedeligt at lave manuelle regressions tests Regression tests bliver derfor ofte udeladt Det kan koste enorme mængder af tid, når man senere finder en mærkelig fejl og ikke aner, hvordan og hvornår den er opstået Løsningen er at lave tests, der let (og automatisk) kan gentages Man definerer en mængde af positive og negative tests Hvilke operationer skal udføres? Hvad skal resultatet være? Derefter er det op til test systemet (i vores tilfælde BlueJ) at gennemføre testene og tjekke om de giver de forventede resultater Det kan gøres på få millisekunder uden programmørens aktive medvirken Med automatiske tests er det langt mere overkommeligt at lave systematiske regression tests 7

8 Automatiske tests i BlueJ BlueJ indeholder et test system ved navn JUnit Nemt at bruge Anvendes i mange andre programmeringsomgivelser for Java Knapper til optagelse og afspilning af tests Gøres synlige ved at trykke på den lille trekantede knap testadddays Den røde plet viser, at vi er i gang med en optagelse Test systemet husker de metodekald, som vi laver Ny klasse Skal indeholde vores tests for Date klassen Er "bundet fast" til Date klassen og flytter sig sammen med denne 8

9 Optagelse af test 3. Kald tostring metoden på date1 objektet Ny del, hvor vi kan definere en assertion, dvs. en betingelse som vi vil have systemet til at tjekke " " 4. Når vi ikke ønsker at udføre mere, afsluttes optagelsen Værdierne af feltvariablerne opdateres Lav et Date objekt 2. Kald adddays metoden 9

10 Den optagne testmetode I DateTest klassen er der tilføjet en ny metode Markeret Indeholder Java kode, der udfører de tre ting vi gjorde under optagelsen Lav et Date objekt ( ) Kald adddays metoden med parameteren 10 Kald tostring metoden og tjek, at den returnerer det forventede resultat (strengen" ") 10

11 Kørsel af testmetode Vi kan nu køre test metoden, ved at trykke på Run tests knappen eller ved at kalde TestAll operationen for klassen DateTest Hvis vi vil ændre i den optagne metode kan vi Lave en helt ny optagelse Modificere Java koden i klassen DateTest " " Stadig OK " " ERROR 11

12 Beskrivelse af hvad der gik galt public void adddays(int d) { for(int i = 0; i<d; i++) { settonextdate(); Hvis parameteren er negativ udføres kroppen af for løkken slet ikke Når man har lavet et par optagelser af test metoder og set, hvordan de ser ud, er det langt hurtigere at skrive test metoderne selv i stedet for at optage dem 12

13 Regressions tests Forberedelser For hver af klassens metoder laves en eller flere testmetoder Disse kan enten optages, eller man kan kode dem direkte i Java Det sidste er forholdsvis let, hvis testmetoden ligner en tidligere Man bruger ofte de samme objekter i mange testmetoder Man kan så (en gang for alle) lave en såkaldt test fixture, der indeholder de pågældende objekter Fixture betyder "fast inventar" detaljer er forklaret i afsnit Hver gang man ændrer en eller flere af klassens metoder Kører man alle testmetoderne ved ét enkelt tryk på Run Tests / TestAll Man kan på få millisekunder se, om alt stadig fungerer som forventet Hvis der findes fejl, skal man overveje, om det er den fejlende metode, der skal ændres, eller det er den angivne assertion, der er forkert Det sidste kan f.eks. være tilfældet, hvis man har ændret en metode til at kunne håndtere specielle input værdier på mere fornuftig vis, f.eks. hvis man har ændret adddays til at kunne få tiden til at gå baglæns (ved negative parameter værdier) 13

14 Kan regressions tests betale sig? Ulemper Det tager en del tid at lave de mange testmetoder Fordele Fejl introduceret på grund af koderettelser findes langt hurtigere og med langt større sandsynlighed Senere kan sådanne fejl være virkelig svære at finde, idet fejlen måske er opstået da man rettede "noget helt andet" Man slipper for kedelige manuelle tests Konklusion Brug tid på (helt fra start) at udvikle test metoder, der kan fungere i forbindelse med automatiske regression tests Det betaler sig i det lange løb også for metoder, der tilsyneladende er forholdsvis simple 14

15 Debugging (aflusning, fjernelse af fejl) BlueJ bogen introducerer tre teknikker til debugging Manual gennemgang af koden Brug af BlueJ's debugger Indsættelse af print sætninger Ideen i de tre er teknikker er den samme Under udførslen af koden, inspicerer man værdierne af udvalgte variabler hvordan metoderne kalder hinanden Forskelle mellem teknikkerne Ved en manual gennemgang klarer man alle beregninger selv. Det tager lang tid og man kan let lave fejl BlueJ's debugger holder styr på variablernes værdier og hvilke metoder der er på kaldstakken. Det sparer tid og debuggeren laver aldrig fejl Men det kræver lidt tid og kræfter, at lære at bruge debuggeren Print sætninger er en mellemting. Tingene beregnes automatisk, men hvis man vil se værdierne af nye variabler må man manuelt ind og tilføje nye print sætninger Derudover er det besværligt at indsætte (og fjerne) print sætninger 15

16 BlueJ's debugger (kort repetition) Nyttig når man skal tjekke den detaljerede opførsel af kørende Java kode Breakpoints indsættes (og fjernes) ved at klikke i venstre margin af editoren Under programudførelsen vil debuggeren stoppe, når et breakpoint nås, og vise positionen med en grøn pil (samt grøn farve) Herefter kan man steppe gennem koden sætning for sætning Mellem skridtene kan man inspicere systemets tilstand, dvs. værdierne af feltvariabler, lokale variabler, osv. 16

17 Metodekald Når næste sætning er et metodekald, har man to muligheder: Udfører hele metodekaldet uden at man ser detaljerne Starter metode-kaldet, men stopper ved første instruktion i den kaldte metode 17

18 Metodekald Parat til at udføre første sætning i den kaldte metode Andre knapper: Fortsætter kørslen frem til næste breakpoint Stopper kørslen Nødstop (uendelig while løkke eller lignende) 18

19 Undervejs kan man inspicere tilstanden Igangværende metodekald Værdier for klassevariabler Værdier for feltvariabler Værdier for lokale variabler 19

20 Eksempel på debugging via print sætninger Klassen Sorting indeholder to klassemetoder list head tail Sortering public static void sort(arraylist<integer> list) { if(list.size() > 1) { int head = list.get(0); list.remove(0); sort(list); Rekursivt kald (på tail) insert(head, list); Indsættelse af element i en sorteret liste public static void insert(int elem, ArrayList<Integer> list) { if(list.size() == 0) { list.add(elem); else { int head = list.get(0); if(elem <= head) { list.add(0, elem); else { list.remove(0); insert(elem, list); list.add(head); Tre tilfælde Listen er tom Elementet er mindre end hovedet Elementet er større end hovedet Rekursivt kald (på tail) 20

21 Testmetode Klassen TestSorting indeholder to metoder Udskriv input og resultat Testmetode public void testsort(int digits) { ArrayList<Integer> list = createarraylist(digits); Sorting.sort(list); System.out.println("sort " + digits + " --> " + list); Hjælpemetode (konstruerer arrayliste ud fra heltal jvf. ekstraopgave i Raflebæger 3) private ArrayList<Integer> createarraylist(int digits) { ArrayList<Integer> list = new ArrayList<>(); while(digits!= 0) { list.add(digits % 10); // Indsæt sidste ciffer i arraylisten digits = digits / 10; // Fjern sidste ciffer Collections.reverse(list); [4, 8, 5, 7, 2] return list; Der er fejl i metoden Det er de rigtige elementer vi har i den sorterede liste Rækkefølgen er ofte forkert For at lokalisere fejlen vil vi indsætte udskrifter i metoderne 21

22 Husk input Hvorfor er det Ikke nok at skrive origlist = list? Udskriv input og resultat public static void sort(arraylist<integer> list) { ArrayList<Integer> origlist = new ArrayList(list); if(list.size() > 1) { int head = list.get(0); list.remove(0); sort(list); insert(head, list); System.out.println("sort " + origlist + " --> " + list); Husk input Udskrifterne kommer i den rækkefølge, som metodekaldene afsluttes Man skal læse nede fra og opad for at få kaldsekvensen Begge metoder fejler Vi prøver sommetider at indsætte i usorteret liste Vi ser først på insert metoden Udskriv input og resultat public static void insert(int elem, ArrayList<Integer> list) { ArrayList<Integer> origlist = new ArrayList(list); if(list.size() == 0) { list.add(elem); else { int head = list.get(0); if(elem <= head) { list.add(0,elem); else { list.remove(0); insert(elem, list); list.add(head); System.out.println("insert " + elem + " in " + origlist + " --> " + list); 22

23 insert metoden har tre cases Indsæt i tom liste elem <= head elem > head public static void insert(...) { if( list.size() == 0 ) {... else { int head = list.get(0); if( elem <= head ) {... else {... Fejlen ser ud til at ligge i denne del Tom liste elem <= head elem > head 23

24 Nu ved vi, hvor vi skal lede efter fejlen Fejlen ser ud til at ligge i denne del public static void insert(int elem, ArrayList<Integer> list) { ArrayList<Integer> origlist = new ArrayList(list); if(list.size() == 0) { list.add(elem); else { int head = list.get(0); if(elem <= head) { list.add(0,elem); else { list.remove(0); insert(elem, list); Hvad er der galt? Hvad skal vi gøre for at rette fejlen? // Fjern head // Indsæt elem i tail // Gendindsæt head list.add(head); list.add(0, head); System.out.println("insert " + elem + " in " + origlist + " --> " + list); list head tail 24

25 Gentag testene Nu ser insert ud til at fungere korrekt Tom liste elem <= head head < elem Det samme er tilfældet for sort metoden I praksis skal man selvfølgelig lave nogle flere tests 25

26 Hvad har vi gjort? Ved at gå systematisk frem lokaliserede vi hurtigt fejlen Både insert og sort fejlede sort kalder insert (men ikke omvendt) Vi startede derfor med at kigge på insert i det håb at sort var ok, men fejlede fordi insert var forkert insert metoden har tre cases Vi testede hver af disse og fandt ud af at fejlen lå i den sidste (elem > head) Den pågældende case bestod af tre sætninger Ved inspektion af disse lokaliserede vi fejlen (som bestod i, at vi genindsatte head sidst i listen, hvor det skulle have været placeret først) Den systematiske tilgang bevirkede, at vi hurtigt kunne koncentrere os om tre linjers kode (i stedet for de ca. 20 linjer, der er i de to metoder) 26

27 Videnskabelig fremgangsmåde Naturvidenskab (f.eks. fysik og astronomi) 1. Observér systemet 2. Opstil en hypotese, som er konsistent med observationerne 3. Lav et eksperiment, som bekræfter/afkræfter hypotesen 4. Modificér hypotesen ud fra eksperimentets resultater 5. Når eksperimentet bekræfter hypotesen, har man en teori, som beskriver de fænomener man kan observere Scientific debugging (science = naturvidenskab) 1. Observér og dokumentér en fejl i systemet 2. Opstil en hypotese om hvad fejlen skyldes 3. Lav et eksperiment, som bekræfter/afkræfter hypotesen 4. Modificér hypotesen ud fra eksperimentets resultater 5. Ret fejlen og kontrollér at fejlen er forsvundet 6. Fortsæt fra 1, hvis der er flere fejl i systemet 27

28 Eksempel på scientific debugging Sortering (kompleks kode, ingen kommenterer) public static void shellsort(arraylist<integer> list, int size) { int i, j; int h = 1; do { h = h * 3 + 1; while(h <= size); do { h /= 3; for(i = h; i < size; i++) { int v = list.get(i); for(j = i; j >= h && list.get(j-h) > v; j -= h) { list.set(j,list.get(j-h)); if(i!= j) { list.set(j,v); while(h!= 1); Kompleks kode Svær at gennemskue [4, 8, 5, 7, 2] Brugervenlig metode (indlæser heltal, skaber arrayliste, kalder shellsort, printer resultatet) public static void sortdigits(int digits) { ArrayList<Integer> list = createarraylist(digits); Sorting.shellSort(list, Integer.toString(digits).length()-1); System.out.println("sort " + digits + " --> " + list); sortdigits metoden returnere ikke altid det rigtige resultat Det er de rigtige cifre Rækkefølgen er sommetider forkert 28

29 Lokalisering af fejlen Vi har observeret at sortdigits fejler for parameterværdien 312 Fejlen kan lige flere steder createarraylist metoden parameterværdierne til shellsort metoden shellsort metoden Det afsluttende print statement public static void sortdigits(int digits) { ArrayList<Integer> list = createarraylist(digits); Sorting.shellSort(list, Integer.toString(digits).length()-1); System.out.println("sort " + digits + " --> " + list); Hypotese 1: Fejlen ligger i createarraylist Experiment: Lav et kald af metoden med parameteren 312 Kræver at vi midlertidigt ændrer private til public Resultat: Metoden returnerer den korrekte arrayliste [3, 1, 2] Hypotesen er forkert 29

30 Lokalisering af fejlen (fortsat) Fejlen kan ligge flere steder??? createarraylist metoden parameterværdierne til shellsort metoden shellsort metoden Det afsluttende print statement public static void sortdigits(int digits) { ArrayList<Integer> list = createarraylist(digits); Sorting.shellSort(list, Integer.toString(digits).length()-1); System.out.println("sort " + digits + " --> " + list); Hypotese 2: Fejlen ligger i parameterværdierne til shellsort Analyse: Metodens dokumentation siger, at anden parameteren skal angive længden af listen i første parameteren Experiment: Kald shellsort med parametrene [3,1,2] og 3 Resultat: Metoden returnerer nu det forventede resultat: [1, 2, 3] Hypotesen er korrekt 30

31 Fejlen er lokaliseret og kan nu rettes Fejlen ligger i anden parameteren til shellsort Integer.toString(digits).length()-1-1 skal fjernes eller hele udtrykket erstattes af list.size() Faktisk er anden parameteren til shellsort helt overflødig Metoden kan selv beregne længden ud fra første parameteren Rest fra gammelt C program, hvor man selv er ansvarlig for at håndtere længden af arrays korrekt Ved at gå systematisk frem sparede vi en masse tid Vi nåede slet ikke at se på shellsort metoden, som er kompleks og vanskelig at forstå Fra det kan vi lære, at det lønner sig at tjekke de simple fejlmuligheder, før man giver sig i kast med de mere komplekse 31

32 Gode råd omkring test og debugging Alle programmer indeholder fejl Anvendelse af gode software udviklingsteknikker (herunder indkapsling, sammenhæng og løs kobling) reducerer antallet af fejl Test bør blive en vane Automatiser test så meget som muligt Husk regression tests, når I modificerer kode Øv jer i at bruge forskellige teknikker til debugging BlueJ's debugger er et fortrinligt værktøj Den kan I med fordel bruge i nogle af de kommende afleveringsopgaver Lav en labrapport / dagbog med de ting, der skal huskes De foretagne design valg (inklusiv begrundelser) Aftestning og debugging Mangler, idéer til forbedringer, osv. Værdien af skriftlighed kan ikke overvurderes Vores hukommelse er forbavsende dårlig Man gentager ofte sine fejl 32

33 Debugging af funktionel kode Lambda'er og streams kan debugges som al anden kode peek metoden gør det nemt at lave print sætninger Intermediate metode, hvor output stream er mage til input stream Undervejs kan vi f.eks. udskrive elementerne public long findsumofageofteenagers() { return persons.stream().peek(.filter( elem elem -> -> print("start: (13 <= elem.getage())) " + )).filter( elem -> (13 (elem.getage() <= elem.getage())) <= 19)).peek(.mapToInt( elem elem -> print("13 -> elem.getage()) <=: " + elem)).filter(.sum(); elem -> (elem.getage() <= 19)).peek( elem -> print("19 >=: " + elem)).maptoint( elem -> elem.getage()).peek( elem -> print("maptoint: " + elem)).sum(); private void print(object o) { System.out.println(o); 33

34 Afleveringsopgave: Debugging + Test I denne opgave skal I træne debugging og konstruktion af automatiske tests, dvs. brug af de teknikker som er beskrevet i denne forelæsning Den metode, som i arbejder på, er så simpel, at I sagtens kan finde fejlen ved blot at kigge på koden Lad være med det Brug i stedet de beskrevne debugging teknikker, således at I bliver fortrolige med dem 34

35 Projektopgave om computerspil I kursets sidste fem uger skal I, sammen med en makker, programmere et computerspil Den første af ugens øvelsesgange bruges på projektopgaven Hver uge tilføjer I ting, som I har lært om i de foregående uger De fem delafleveringer tæller tilsammen med ca. 30% i den endelige karakter for kurset For hver delaflevering får man op til 6 point 6 = fremragende ( 12) ingen eller få uvæsentlige mangler 5 = fortrinlig ( 10) nogle mindre væsentlige mangler 4 = god ( 7) en del mangler (rettes i næste delaflevering) 3 = jævn ( 4) adskillige væsentlige mangler (rettes i næste delaflevering) 2 = tilstrækkelig ( 02) godkendt efter genaflevering 1 = utilstrækkelig ( 00) ikke godkendt (fejlene rettes i genaflevering) Hvis man skal genaflevere, kan man højst få 2 point Det samme er tilfældet, hvis man afleverer for sent (uden gyldig grund) Hvis man ikke får rettet fejl fra de foregående afleveringer trækker de ned en gang til 35

36 Klassediagram Det færdig projekt indeholder 25 klasser, hvoraf I skal skrive 14 og lave ændringer i yderligere 2 36

37 Afleveringsopgave: Computerspil 1 I skal programmere et computerspil, hvor spillerne rejser rundt mellem byer i forskellige lande og indsamler point I første delaflevering skal I bl.a. modellere byerne og vejene imellem dem, samt de lande byerne ligger i. Når I er færdige, vil I kunne spille Der er forholdsvis meget at lave, men langt de fleste af tingene er lette at implementere En af instruktorerne lavede en løsning på ca. 30 minutter For at spare tid må I rent undtagelsesvis vente med at dokumentere de klasser, konstruktører og metoder, som I skriver 37

38 Brug af Test Fixture Når man skal afteste metoderne i Country og City klasserne, har man behov for at kunne skabe Country objekter Dette er lidt bøvlet, idet klassens konstruktør har en parameter af typen Map<City, List<Road>> En første løsning er at bruge null som parameterværdi En mere sofistikeret løsning er at bruge en Test Fixture som realiserer nedenstående netværk Test Fixturen kan kopieres til Object benchen, som så får nedenstående udseende Opgaveformuleringen forklarer, hvordan Test Fixturen hentes og anvendes

39 Computerspil 2-5 I de næste fire delafleveringer skal I Dokumentere jeres klasser, konstruktører og metoder samt lave regression tests for alle konstruktører og metoder (Computerspil 2). Bruge nedarvning (subklasser) og dynamisk method binding (overskrivning af metoder) til at strukturere jeres kode, således at der er flere forskellige slags lande og flere forskellige slags byer (Computerspil 3). Udvide den grafiske brugergrænseflade med nogle ekstra knapper, labels og tekstfelter (Computerspil 4). Lave automatisk logning af et spil, ved at gemme en passende tekstfil, som så senere kan genindlæses og afspilles for at genskabe det optagne spil (Computerspil 5). 39

40 Opsummering Opremsningstyper Enumerated types Forskellige teknikker til test og debugging Når man tester undersøger man, om opførslen (semantikken) er den ønskede Når man debugger (afluser), forsøger man at finde ud af, hvorfor opførslen ikke er, som man ønskede og forventede Projektopgave om computerspil I kursets sidste fem uger skal I, sammen med en makker, programmere et computerspil Der er fem delafleveringer og de indgår tilsammen med ca. 30% i den endelige karakter for kurset 40

41 Det var alt for nu.. spørgsmål 41