3.9 Feilsøking og testing av programmer

Feil er ikke nederlag

Alle programmerere lager feil. Det er en helt naturlig del av å skrive kode, og det gjelder både nybegynneren og veteranen. Forskjellen mellom dem er ikke at den erfarne gjør færre feil -- det er at hun er flinkere til å finne og rette dem. Feilsøking er derfor en av de viktigste ferdighetene du kan lære.

Feil deler seg i tre hovedtyper. Syntaksfeil bryter selve reglene i programmeringsspråket, og programmet starter ikke engang. Kjøretidsfeil dukker opp mens programmet kjører, og får det til å krasje underveis. Logiske feil er de lumskeste: programmet kjører helt fint, uten en eneste feilmelding, men gir likevel feil svar.

I dette kapittelet skal du lære å skille disse tre fra hverandre, å feilsøke systematisk med print-setninger, å lese og tolke Python sine feilmeldinger, og å teste koden din med assert og smarte grensetilfeller.

De tre feiltypene

La oss bli kjent med de tre. En syntaksfeil oppstår når koden bryter språkets regler -- glemmer du kolon etter en if, eller rykker inn feil, stopper Python med en SyntaxError eller IndentationError før programmet kommer i gang. Disse er ofte de enkleste å rette, fordi Python forteller deg nøyaktig hvor det skar seg.

En kjøretidsfeil lar programmet starte, men så krasjer det. Prøver du å hente tall[5] fra en liste med tre elementer, får du en IndexError. Deler du på null, kommer ZeroDivisionError. Prøver du int("hei"), får du ValueError. Programmet kjørte helt til det punktet, og så stoppet det opp.

Den vanskeligste er logisk feil. Her er koden teknisk feilfri -- ingen feilmeldinger -- men resultatet er galt. Skriver du gjennomsnitt = sum_tall / antall + 1 når du mente sum_tall / (antall + 1), kjører alt, men svaret blir feil. Python kan ikke vite hva du mente. Et godt eksempel: vil du regne arealet av en sirkel og skriver 2 * pi * r, har du regnet ut omkretsen i stedet, og ingen feilmelding advarer deg. Det er nettopp derfor logiske feil krever mest detektivarbeid.

Print-debugging og systematisk jakt

Den enkleste og mest brukte feilsøkingsteknikken er print-debugging -- du legger inn print()-setninger for å se hva som faktisk skjer inne i programmet. Strategien er enkel: finn ut hvor feilen trolig sitter, skriv ut variabelverdiene der, kjør og analyser, flytt printene for å snevre inn, og fjern dem til slutt. Et godt triks er å merke dem med DEBUG: så de er lette å finne igjen.

La oss se det i aksjon. Et program skal finne det største tallet i en liste, men starter med storst = 0. Med listen [-3, -1, -7, -2] returnerer den 0, ikke -1. Legger vi inn print-setninger, ser vi at hvert tall sammenlignes mot 0, og siden alle er negative, blir ingen større enn 0. Feilen er startverdien! Løsningen er å sette storst = tall[0] -- altså bruke første element som utgangspunkt. Print-debugging gjorde den usynlige logiske feilen synlig.

Men den aller viktigste informasjonen ligger ofte i selve feilmeldingen. En Python-Traceback forteller deg tre ting: filen og linjenummeret der det skjedde, feiltypen (som IndexError), og en kort beskrivelse (som "list index out of range"). En systematisk fremgangsmåte er da: les feilmeldingen nøye, isoler feilen ved å kommentere ut kode og teste med enkle verdier, forstå forskjellen mellom hva du forventet og hva koden faktisk gjør, og rett så feilen med én endring om gangen før du tester på nytt. Akkurat denne disiplinen -- rotårsak før fiks -- skiller god feilsøking fra ren gjetting.

Testing med assert og edge cases

Det beste er å fange feil før de rekker å gjøre skade. Til det bruker vi assert -- et Python-nøkkelord som sjekker om en betingelse er sann. Er den usann, krasjer programmet med en AssertionError, og du vet umiddelbart at noe er galt. Skriver du assert beregn_areal(5, 3) == 15, "5 × 3 skal gi 15", har du laget en liten, automatisk test. Kjører hele rekken med tester uten å klage, kan du puste lettet ut.

Men hvilke verdier bør du teste med? Her kommer edge cases inn -- grensetilfellene der feil ofte gjemmer seg. Det er ting som en tom liste eller streng, tallet 0, negative tall, svært store tall, eller at alle verdiene er like. En funksjon som regner gjennomsnitt bør for eksempel håndtere en tom liste uten å dele på null, og en funksjon som sjekker gyldig alder bør testes nøyaktig på grensene 0 og 150 -- og rett utenfor, på -1 og 151. Det er nettopp på kanten ting pleier å briste.

Et godt eksempel på hvordan feiltypene samler seg: tenk en funksjon med tre feil på én gang. Mangler det kolon etter def beregn_statistikk(malinger), er det en syntaksfeil. Skriver du range(antall + 1) på en liste med fem elementer, går du ett steg for langt og får malinger[5] -- en kjøretidsfeil med IndexError. Og regner du gjennomsnittlig avvik som sum(avvik) / antall, blir svaret alltid null fordi positive og negative avvik opphever hverandre -- en logisk feil som du må rette med absoluttverdier. Tre feil, tre kategorier, og samme systematiske jakt løser dem alle.

Oppsummering

Feilsøking er en ferdighet, ikke et nederlag. Vi skiller mellom syntaksfeil, som bryter språkets regler og stopper programmet før start; kjøretidsfeil, som krasjer programmet underveis med meldinger som IndexError og ZeroDivisionError; og logiske feil, som gir feil svar helt uten advarsel.

Print-debugging gjør usynlige verdier synlige, og en god Traceback forteller deg linjenummer, feiltype og beskrivelse. Den systematiske fremgangsmåten -- les, isoler, forstå, rett, test -- er rotårsak før fiks i praksis. Til slutt lar assert og bevisst valg av edge cases som tomme lister, null og grenseverdier deg fange feil før de gjør skade. Med disse verktøyene blir du ikke en programmerer uten feil, men en som finner dem raskt.