De hele opdracht met echte regressietests bewaken

Alle onderdelen van het urenrapport hebben hun eigen afspraken. Toch kan een wijziging in de verbinding ertussen het eindresultaat veranderen. In deze laatste les schrijf je regressietests die een echte bron via de CLI tot een echt uitvoerbestand laten lopen.

Het geheel heeft een eigen contract

Een losse parsertest bewijst niet dat de CLI de gekozen datums doorgeeft. Een goede JSON-serializer bewijst evenmin dat een mislukte opdracht het oude rapport bewaart. Een integratietest verbindt daarom de onderdelen die samen de gebruikersopdracht uitvoeren.

Onze tests gebruiken de bestaande main-functie met expliciete argumenten. Zij maken tijdelijke bestanden, lezen de werkelijk geschreven uitvoer en vergelijken de resultaten. Daarvoor hoeven zij geen subprocess of netwerkdienst te starten.

Een test is een echte uitvoering

import unittest

class Totals(unittest.TestCase):
    def test_sum(self):
        self.assertEqual(20 + 15, 35)

suite = unittest.defaultTestLoader.loadTestsFromTestCase(Totals)
result = unittest.TestResult()
suite.run(result)
print(result.testsRun)
print(result.wasSuccessful())

1
True

Het voorbeeld laat de unittest-loader een test vinden en de suite werkelijk uitvoeren. Het resultaat meldt hoeveel tests zijn gelopen en of zij geslaagd zijn. Alleen een functienaam met test erin is nog geen uitgevoerde controle.

De meegeleverde DeliveryTests bevat alvast een tijdelijke werkmap en een source-helper. Met addCleanup wordt de map ook na een mislukte assertion opgeruimd. Iedere test krijgt zo eigen bestanden en een eigen beginstand.

Verwachtingen komen uit de afspraak

De drie demonstratieregistraties bevatten zestig, vijfenveertig en veertig minuten. Hun totaal is 145, met balie1/45 en bouw2/100. Deze waarden leg je onafhankelijk vast in assertions.

Laat make_report niet eerst de verwachte waarde berekenen voor een test van dezelfde opdracht. Een fout in die functie zou dan zowel de verwachting als het echte resultaat veranderen. Je vergelijking kan groen blijven terwijl de gebruiker een verkeerd rapport ontvangt.

Kleine grenzen maken regressies zichtbaar

Een selectie van alleen twee oktober levert precies de balie-registratie op. Dat korte geval onderscheidt een genegeerd filter van een echte selectie en maakt het uitsluiten van de einddag zichtbaar. Controleer ook de periodemetadata, zodat de betekenis van het bestand vastligt.

Bij ongeldige invoer hoort een ander pad. Maak vooraf een herkenbaar oud rapport, voer de verkeerde bron in en controleer zowel status twee als de ongewijzigde inhoud. Eén van die twee voorwaarden alleen dekt het herstelcontract niet.

Veelgemaakte fout: bestaan verwarren met correctheid

Een bestand met de extensie csv kan nog steeds JSON bevatten. Een bestaande file kan ook een onvolledige tabel zijn. Lees daarom de echte CSV-rijen en vergelijk de kop én de gegevenswaarden.

import unittest

class Totals(unittest.TestCase):
    def test_sum(self):
        self.assertEqual(20 + 15, 40)

suite = unittest.defaultTestLoader.loadTestsFromTestCase(Totals)
result = unittest.TestResult()
suite.run(result)
print(result.testsRun)
print(result.wasSuccessful())
print(len(result.failures))

1
False
1

De tweede suite heeft een echte assertion die faalt. Dat is bruikbaar bewijs dat de verwachting iets onderscheidt. Een skip, expectedFailure of ontbrekende test levert diezelfde zekerheid niet.

De toets controleert ook je tests

De oefenomgeving draait je geselecteerde unittest-test eerst tegen de juiste projectbestanden. Daarna krijgt dezelfde test volledige projectkopieën met concrete regressies, bijvoorbeeld een verkeerd totaal of een beschadigd oud rapport. Zo wordt zichtbaar of jouw assertions de afgesproken fout daadwerkelijk afwijzen.

Een onverwachte programmeerfout in de test telt daarbij niet als een gevonden regressie. De verkeerde projectvariant moet op een echte assertion stuklopen. De juiste variant moet volledig slagen, zonder overgeslagen controles.

Opleveren met concrete grenzen

Deze regressies komen boven op de gerichte parser-, model-, I/O- en foutproeven uit de vorige lessen. Zij bewijzen de gekozen opdrachten en gevallen, samen met de verklaarde aannames over de uitvoermap. Een wijziging is pas af wanneer die relevante controles opnieuw zijn uitgevoerd.

Samenvatting

• Integratietests gebruiken echte bronnen, argumenten en uitvoerbestanden.
• Een onafhankelijke verwachting voorkomt dat een productfout zichzelf goedkeurt.
• Een bruikbare test slaagt op de juiste variant en herkent concrete regressies.