Att testa sina program är en självklarhet, annars vet man ju inte om de fungerar. Det är en sak att få sitt program att kompilera, en annan att sak att det verkligen gör det man vill att det ska göra.
Man måste testa att programmet fungerar för
Det finns en modul i python - doctest - som kan tolka tester i kodkommentaren. Man kan klistra in en testkörning av funktionen och den kommer att utföras. Här följer ett exempel på get()-funktionen i en köklass (se labb 2).
class Queue:
"En köklass"
# Kod i köklassen
def get(self):
"""
Returnerar och tar bort det som står först i kön.
>>> q = Queue()
>>> q.put(5)
>>> q.put(3)
>>> q.get() == 5
True
""" # """ (html)
# Här börjar koden i funktionen
x = self.first.value
self.first = self.first.next
return x
# Mer kod i köklassen
def _test():
import doctest
doctest.testmod()
if __name__ == "__main__":
_test()
Kör vi funktionen _test() får vi en utmatning som berättar vilka tester som görs. Vore köklassen felaktigt implementerad så get() returnerade något annat än 5 skulle vi få följande svar:
**********************************************************************
File "queue.py", line 22, in __main__.Queue.get
Failed example:
q.get == 5
Expected:
True
Got:
False
**********************************************************************
1 items had failures:
1 of 4 in __main__.Queue.get
***Test Failed*** 1 failures.
Det behövs många tester för att testa stora system och alla dessa går inte att skriva i kodkommentarer för då blir inte kommentaren läslig. Istället skriver man egna testklasser som bara har till uppgift att testa en eller flera klasser i systemet. För att testa igenom hela systemet kör man sedan alla testfall i alla testklasser. I python finns ett paket - unittest - som man använder för detta.
Ett viktigt skäl till testning är att göra regressionstest, d.v.s. att kontrollera att den befintliga koden inte påverkas i oönskad riktning då man tillför eller ändrar någon annanstans. Om systemet är stort medför det ofta att många tusentals test måste göras varje gång något ändras i koden. Att automatisera testningen är nödvändigt.
Odokumenterade tester är värdelösa! Får man under utvecklingen av ett system en felrapport från ett test måste man snabbt kunna få veta vad för slags fel det är, helst så noggrant beskrivet som möjligt. All testkod måste alltså också dokumenteras så det är lätt att felsöka.
Kattis började i form av Marvin, som användes för att rätta inlämningarna i programmeringstävlingskursen
DD2458 (programmering och problemlösning under press), men används numera även i DD1352 (Algoritmer, Datastrukturer och Komplexitet) och DD2387 (Programsystemkonstruktion med C++).
Kattis är skrivet i en kombination av Python, PHP och SQL och körs på en Ubuntu-server. En specialbyggd säkerhetslösning används för att hindra fusk. All inskickad kod lagras också för att senare kunna kontrollera koden ifall det skulle behövas.
Den pedagogiska tanken med Kattis är att eleverna skall kunna sända in sin kod och snabbt få svar på huruvida koden fungerar. Kattis skall även ge eleverna övning i att söka efter buggar i koden. Kattis har utvecklats av följande personer:
from sys import stdin
inrad = stdin.readline()
while inrad:
lista = inrad.split()
tal1 = int(lista[0])
tal2 = int(lista[1])
...
inrad = stdin.readline()
print x