Slik tester du koden din med Python unittest uten å gå deg vill

Mange som lærer Python utsetter testing til slutt, eller hopper over det helt. Resultatet blir ofte kode som er vanskelig å endre, feilsøke og stole på, spesielt når prosjektet vokser.

I denne artikkelen ser vi på hvordan du kan bruke den innebygde testmodulenunittesti Python for å skrive forståelige og nyttige tester, steg for steg. Målet er at du skal kunne teste egen kode på en trygg og ryddig måte.

Hva er unittest, og hvorfor bry seg?

unittester Pythons standardbibliotek for enhetstesting. Det følger med alle vanlige Python-installasjoner, så du slipper å installere noe ekstra for å komme i gang.

Enhetstester er små tester som sjekker at en spesifikk funksjon eller klasse oppfører seg som forventet. Når du endrer kode, kan du kjøre testene på nytt og raskt se om du har ødelagt noe som fungerte før.

Et lite eksempelprosjekt vi kan teste

Vi starter med en enkel fil,calculator.py, som inneholder noen funksjoner det er naturlig å teste. Poenget er ikke å lage avansert matematikk, men å ha noe konkret å jobbe med.

Lag filencalculator.pymed dette innholdet:

calculator.py

def add(a, b):
return a + b

def divide(a, b):
if b == 0:
raise ValueError("Cannot divide by zero")
return a / b

Slik strukturerer du en unittest-fil

En vanlig praksis er å legge testene i en egen fil med navn som starter medtest_, for eksempeltest_calculator.py. Det gjør det lettere for både deg og ulike verktøy å finne testene.

Lag filentest_calculator.pyi samme mappe somcalculator.py, og start slik:

test_calculator.py

import unittest
from calculator import add, divide

class TestCalculator(unittest.TestCase):
pass

if __name__ == "__main__":
unittest.main()

Din første assert: sjekk at resultatet stemmer

Inne i klassenTestCalculatorlegger du metoder som starter medtest_. Hver slik metode er én test. Inne i testmetodene bruker du ulikeassert-metoder for å sjekke at resultatene er som forventet.

La oss testeadd-funksjonen:

test_calculator.py

class TestCalculator(unittest.TestCase):

def test_add_positive_numbers(self):
result = add(2, 3)
self.assertEqual(result, 5)

def test_add_negative_numbers(self):
result = add(-2, -3)
self.assertEqual(result, -5)

Hvordan kjøre testene

For å kjøre testene, åpner du et terminalvindu i samme mappe og kjører:

python -m unittest test_calculator.py

Hvis alt er riktig, får du en kort rapport. Ett punktum betyr én grønn test. Hvis noe feiler, ser du en detaljert feilmelding som viser hvor og hvorfor.

Teste at feil faktisk kastes

Det er ikke bare “suksess-scenarier” som bør testes. Du bør også teste at funksjonen håndterer feil slik du har planlagt, for eksempel når noe skal gi unntak.

La oss teste atdividekasterValueErrornår vi prøver å dele på null:

test_calculator.py

class TestCalculator(unittest.TestCase):
# ... tidligere tester ...

def test_divide_by_zero_raises_value_error(self):
with self.assertRaises(ValueError):
divide(10, 0)

Gode navn gjør testene lesbare

Navngiving er viktig for at testene skal være til hjelp også om noen måneder. Når en test feiler, er testnavnet ofte det første du ser.

Som tommelfingerregel kan du bruke dette mønsteret:test_funksjon_scenario_forventet_resultat. For eksempeltest_divide_valid_numbers_returns_float.

Set up og tear down: felles forberedelser

Noen ganger trenger flere tester den samme forberedelsen, for eksempel å opprette et objekt eller fylle en midlertidig mappe. Da kan du brukesetUpogtearDown.

Disse metodene kjøres før og etter hver testmetode i klassen:

class TestSomething(unittest.TestCase):

def setUp(self):
self.values = [1, 2, 3]

def tearDown(self):
self.values = None

def test_length(self):
self.assertEqual(len(self.values), 3)

Når bør du skrive tester?

Det er fristende å skrive all koden først og teste til slutt, men det blir ofte tyngre. Mange synes det er mer motiverende å skrive små biter kode, og teste dem med en gang.

Noen jobber også medtestdrevet utvikling (TDD), der du skriver testen før selve funksjonen. Du begynner med å definere ønsket oppførsel i en test, ser den feile, og skriver så nok kode til at testen går grønt. Dette krever øvelse, men gir ofte ryddigere design.

Vanlige fallgruver og hvordan unngå dem

En typisk feil er å skrive for store tester som sjekker “alt mulig”. Da blir det vanskelig å se hva som egentlig gikk galt når testen feiler. Prøv heller å holde hver test til én tydelig forventning.

En annen felle er å gjøre testene avhengige av nettverk, eksterne API-er eller ekte databaser. Slike tester kan bli trege og ustabile. For nybegynnerprosjekter kan du ofte starte med å teste ren logikk, uten eksterne avhengigheter.

Slik kommer du videre

Når du er komfortabel medunittest, kan du utforske mer avanserte teknikker som testdekning, mocking og testdata for mer komplekse systemer. Du kan også se på alternative testrammeverk sompytest, som tilbyr en annen stil.

Det viktigste er ikke hvilket rammeverk du velger, men at du gjør testingen til en naturlig del av arbeidsflyten din. Start smått, test funksjoner du faktisk bryr deg om, og bygg videre derfra.