Kodetesting

Det er ikke mulig å snakke om testing uten å sitere en av pionerene i datafaget: Edsger W. Dijkstra. [1] , [2] Han sa for over 30 år siden mye som kan leses med stort utbytte også idag, se referanser nedenfor. En av de tingene han er sitert på er:

Program testing can be used to show the presence of bugs, but never to show their absence!

En konsekvens av dette er at vi aldri kan påstå at et program er feilfritt. Vi kan i beste fall hevde at det er "godt nok". Det er gjort mange forsøk opp gjennom datafagets levetid å angripe programkonstruksjon fra et abstrakt matematisk vinkel for å forsøke å finne programmeringsteknikker der en kan bevise at programmet gjør det som er spesifisert. Den praktisk nytten av dette er liten. Det vi nok kan si som en konsekvens av denne tenkingen er at det finnes programmeringsstiler som er bedre enn andre med tanke på å minimalisere feil. Strukturet programmering med alt det innebærer, f.eks. at alle blokker skal ha en inngang og en utgang er en del av dette.

I praktisk programmering sitter vi med Dijkstras sitat som premiss for vårt testarbeid, vår kvalitetskontroll.

XP (eXtreme Programming) er en utviklingsfilosofi som setter sterkt fokus på testing: "Skriv testen før koden". Vi ser også at testverktøy og testeknikker blir en vanligere del av de språkene og de utviklingsmiljøene vi bruker. Mesteparten av dette har referanser tilbake til et arbeid som er gjort av Ken Beck [3] . Det er fra dette arbeidet vi finner begrepet Unit slik som det er brukt i JUnit for Javatesting, PyUnit for Pythontesting, JSUnit for Javascripttesting, NUnit for .Net-språkene osv.