Indledende Programmering Uge 5 - Efterår 2006 Om at udvikle korrekte og pålidelige programmer Susanne Lindros.

Præsentationer af emnet: "Indledende Programmering Uge 5 - Efterår 2006 Om at udvikle korrekte og pålidelige programmer Susanne Lindros."— Præsentationens transcript:

1 Indledende Programmering Uge 5 - Efterår 2006 Om at udvikle korrekte og pålidelige programmer Susanne Lindros

2 Plan for Automatiseret Test Kvalitetskriterier Testplanlægning Automatiseret test med JUnit Om at indbygge vedligeholdelsesvenlighed Debugging –Skrivebordstest –Testudskrifter –BlueJ’s debugger At teste er at lede efter tilstedeværelsen af fejl. At debugge er at finde ud af hvorfor det fejler.

3 Kvalitetskriterier Vedligeholdelsesvenlighed Skriv kode så du undgår fejl i første omgang Skriv kode der gør det let at finde og rette de fejl der alligevel opstår Midler til at opnå vedligeholdelsesvenlighed –Kommentarer, strukturering, modularisering, veldefinerede grænseflader Korrekthed og pålidelighed Programmet leverer logisk korrekte resultater og opfører sig altid på samme måde. F.eks. går det ikke pludselig ned engang imellem Midler til at opnå korrekthed og pålidelighed: –Finde fejl (de er der altid) ved at teste programmet –Rette fejl ved at debugge programmet

4 Fejltyper og testtilfælde Syntaksfejl: fanges af oversætteren Logiske fejl: forsøges fanget ved tests Testtilfælde: –Find de principielt forskellige situationer som programmet skal kunne håndtere Husk både positive og negative tests Husk grænsetilfældene

5 Oversigt over testtilfælde Gå metoderne igennem og se på de involverede værdier (husk grænsetilfælde, positive og negative tests) MetodeTesttilfældeForventet resultat makeAppointment()Ledig dagAftale registreret kl 9 makeAppointment()Booking af allerede optaget tid Ny aftale ikke registreret makeAppointment()Booking af 2 timers aftale kl 11 hvor der findes en 1times aftale kl 12 Ny aftale ikke registreret findSpace()Ledig dag med start 9Returnerer 9 findSpace()Fuldbooket dagReturnerer -1

6 Automatiseret Test Manuel test (evt. med BlueJ – kap 6.3) –Man må selv checke at programmet giver de rigtige resultater –Usikkert fordi man overser fejl Fejlrettelser forbedrer ikke altid programmerne –Fejlen rettes men nye fejl dukker op i stedet Regressions-test er vigtig –Efter hver ændring gentages alle tidligere tests –Sikrer at alt det der virkede før rettelsen stadig virker Regressions-test kræver automatiseret test –Et program udfører testen og kontrollerer resultaterne

7 JUnit test Unit Testing: –Test af de enkelte enheder, f.eks. klasser og metoder JUnit: –Java API, der understøtter regressionstest baseret på Unit Testing –Integreret i BlueJ –Kan downloades fra www.junit.org og anvendes uden for BlueJwww.junit.org

8 Basis strukturen i JUnit En testklasse for hver klasse i programmet Testmetoder i testklassen, der tester de enkelte testtilfæde Testmetode checker om tilstanden af et objekt før og efter udførelsen af én eller flere metoder er som forventet Assert metoderne fra JUnit API’et anvendes til at udføre dette check, f.eks. assertEquals()

9 Basis strukturen i JUnit Testklassens fixture (test objekter) kan oprettes i setUp() metoden ”Skelettet” af testklassen genereres automatisk Testmetoderne og testklassens fixture genereres ved ”indspilning”

10 Automatiseret Test med JUnit Skabelon for JUnit test klasse public class DayTest extends junit.framework.TestCase { // Opretter test fixture. Bliver kaldt inden hver testmetode protected void setUp() { } // Nedlægger test fixture. Bliver kaldt efter hver testmetode protected void tearDown() { } // Testmetode: Checker metode i klasse under test public void testDoubleBooking() { }

11 Vedligeholdelsesvenlighed Midler: –Kommentarer, strukturering, modularisering, veldefinerede grænseflader Modularisering – hvorfor? –Modulerne kan udvikles individuelt –Lettere at ændre, teste og debugge Klar specificering af modulernes interfaces –Gør dem lettere at udvikle (parallelt?) –Gør dem lettere at integrere

12 Modularisering i en lommeregner De enkelte moduler behøver ikke at vide noget om hinanden: –Brugergrænsefladen kunne være en GUI eller en hardware enhed –Den aritmetiske logik kunne være implementeret som hardware eller software

13 Metode signaturer som interface // Return the value to be displayed. public int getDisplayValue(); // Call when a digit button is pressed. public void numberPressed(int number); // Call when a plus operator is pressed. public void plus(); // Call when a minus operator is pressed. public void minus(); // Call to complete a calculation. public void equals(); // Call to reset the calculator. public void clear();

14 Debugging Flere måder at finde og rette fejl på: –Inspektion af kildeteksten (Verbal walkthrough) –Trinvis udførelse af programmet og observation af variablernes værdiskift (tilstandsskift) Vha. debugger værktøj (chapter. 3.13) Vha. skrivebordstest (Manual walkthrough) –Indsæt testudskrifter i programmet (Print statements) Opgave 5 – Trace af TicketMachine

15 Inspektion af kildeteksten Verbal walkthrough Forklar nogen andre hvad din metode eller klasse laver –Måske finder de fejlen –Måske finder du selv fejlen mens du forklarer Tilsvarende formel metode: “inspections”

16 Test og debugging hvad skal jeg vælge? Test: –Automatiser hvor det er muligt –Vælg teknikker der ikke ændrer koden Debugging: –Vælg helst teknikker der ikke ændrer koden