Kap 5.5 – Testning, dokumentation och reflektion

Mål med lektionen

När du har arbetat klart med denna lektion ska du:

• Förstå varför testning är en viktig del av programutveckling.
• Kunna testa ditt program systematiskt med olika indata och kontrollera resultat.
• Dokumentera din kod så att andra, och du själv, förstår den.
• Reflektera över din arbetsprocess och vad du lärt dig under projektet.

Så här lär du dig bäst

Gå tillbaka till ditt projekt och tänk som en utomstående testare: vad kan gå fel? Vad händer om användaren matar in något oväntat? Dokumentera tydligt hur programmet fungerar och skriv kommentarer som förklarar syfte och funktion i viktiga delar. Skriv sedan en kort reflektion över vad du har lärt dig, vilka utmaningar du stött på och hur du löste dem.

Ett vanligt misstag är att bara testa programmet när allt skrivs in korrekt. Då vet du bara att programmet fungerar i bästa fall. Ett färdigt projekt behöver också testas när användaren gör fel, när data saknas och när programmet körs flera gånger i rad.

Centrala begrepp

• Testfall - Specifika situationer som testas i programmet, ofta med förväntat utfall.
• Felhantering - Att identifiera och hantera problem, till exempel felaktig inmatning eller trasig databasanslutning.
• Kommentarer - Förklarande text i koden som inte påverkar programmets funktion.
• README - En textfil som beskriver programmet, dess syfte, funktion och hur man använder det.
• Reflektion - Att tänka tillbaka på hur arbetet gått och vad man lärt sig.

1. Testa ditt program

Kontrollera vad som händer i både vanliga och ovanliga situationer. Testa till exempel:

• Rätt och fel inmatning.
• Tomma fält.
• Specialtecken.
• Extremt långa värden.
• Avslut och avbrott.

Använd gärna en checklista där du skriver vad du testar, vilken indata du använder och vad du förväntar dig att programmet ska göra.

Olika typer av testfall

Försök att blanda flera typer av testfall. Då blir testningen mer systematisk.

• Normala testfall - användaren skriver det programmet förväntar sig.
• Feltest - användaren skriver fel typ av data, till exempel text där ett tal krävs.
• Gränsfall - värden som ligger precis på gränsen, till exempel 0, tom sträng eller väldigt långt namn.
• Upprepade test - samma funktion körs flera gånger för att se att programmet inte bara fungerar första gången.

Exempel: testfall för ett databasprojekt

Om ditt projekt använder SQLite kan testningen till exempel se ut så här:

Skriv gärna resultatet efter att du testat. Då kan du tydligt visa vad som fungerar och vad som behöver förbättras.

2. Dokumentera koden

Kommentarer ska hjälpa läsaren att förstå syftet med koden. Det görs ofta på engelska i professionella projekt, men i den här kursen kan du välja svenska eller engelska.

def add_recipe():
    # Hämtar input från användaren och lägger till recept i databasen
    ...

En bra kommentar förklarar sådant som inte redan är uppenbart av kodens namn. Kommentera särskilt kod som hanterar fel, databasanslutningar, API-anrop eller annan logik där det är lätt att missa varför koden finns.

Mindre bra och bättre kommentarer

# Mindre bra: upprepar bara raden
antal = antal + 1  # ökar antal med 1

# Bättre: förklarar varför räknaren ändras
antal = antal + 1  # räknar hur många poster som faktiskt sparades

Skapa också en README-fil för projektet. Den bör innehålla:

• Programbeskrivning.
• Funktioner.
• Hur man kör programmet.
• Eventuella kända buggar eller begränsningar.

Exempel på README-struktur

# Projektets namn

Kort beskrivning av vad programmet gör.

## Funktioner
- Lägg till data
- Visa data
- Sök efter data

## Så kör du programmet
1. Öppna projektmappen.
2. Kör main.py.
3. Följ menyn i terminalen.

## Kända begränsningar
- Programmet hanterar ännu inte alla typer av felaktig inmatning.

En README ska hjälpa någon annan att komma igång utan att behöva läsa all kod först. Därför är det bra att skriva konkret: vilken fil startar programmet, vilka paket behövs och vad kan användaren göra?

README-checklista

• Finns projektets syfte beskrivet med en eller två meningar?
• Står det vilken fil som ska köras, till exempel main.py?
• Står det om projektet använder sqlite3, requests eller tkinter?
• Finns exempel på hur användaren använder programmet?
• Finns kända begränsningar eller saker du vill förbättra senare?

3. Reflektera

Svara på dessa frågor i din reflektion, muntligt eller skriftligt:

• Vad fungerade bäst i projektet?
• Vad var mest utmanande?
• Hur löste du problem du stötte på?
• Vilka delar av programmering förstår du bättre nu?
• Vad vill du lära dig mer om?

En bra reflektion är konkret. Skriv inte bara "det gick bra" eller "det var svårt". Beskriv vad som gick bra, varför det gick bra, vad som var svårt och hur du tog dig vidare.

Exempel på reflektion

Det som fungerade bäst var att dela upp projektet i main.py och databas.py. Då blev det tydligare vilken kod som hanterade menyn och vilken kod som pratade med databasen. Det svåraste var att hantera tom sökning, eftersom min första version visade alla poster. Jag löste det genom att kontrollera sökordet innan SQL-frågan kördes. Nästa gång vill jag testa tidigare och skriva testfall redan när jag bygger varje funktion.

Reflektionsmall

• Planering: Hur hjälpte planeringen dig? Vad saknades?
• Implementation: Vilka delar byggde du först och varför?
• Problem: Vilka fel eller svårigheter uppstod?
• Lösningar: Hur hittade du orsaken och vad ändrade du?
• Testning: Vilka testfall visade att programmet fungerade?
• Vidareutveckling: Vad skulle du förbättra om du fortsatte?

Arbetsgång innan inlämning

1. Kör programmet från början och kontrollera att det startar utan fel.
2. Testa vanliga fall, felaktig inmatning och gränsfall.
3. Skriv ner testfallen och resultatet.
4. Läs igenom koden och lägg till kommentarer där de faktiskt hjälper.
5. Skriv eller uppdatera README-filen.
6. Skriv reflektionen medan du fortfarande minns problemen och lösningarna.

Sammanfattning

• Du har testat programmet med olika scenarier.
• Du har dokumenterat din kod och skapat en README-fil.
• Du har reflekterat över hur du arbetat och vad du lärt dig.
• Du har sett hur testfall, dokumentation och reflektion visar kvaliteten i projektet.
• Du har utvecklat både tekniska och analytiska färdigheter.