Onderzoek de grens in pdb

Het geval ligt nu vast: aantal 4, drempelwaarde 4, een item dat behouden had moeten blijven maar wegviel. Je zou de vergelijking goed kunnen bekijken en de oorzaak waarschijnlijk raden. De debugger biedt iets beters dan een gok: hij stopt de echte uitvoering op de echte regel, met de echte waarden voor je neus.

Start het programma onder de ingebouwde debugger van Python:

python -m pdb catalog.py catalog.csv selected.json --minimum-quantity 4

Je krijgt een (Pdb)-prompt in plaats van een resultaat. Het programma is geladen, maar nog niet uitgevoerd.

Stop op de regel die beslist

Je wilt binnen select_items pauzeren, op de vergelijking die bepaalt of een item behouden blijft. Laat pdb die vinden in plaats van zelf regels te tellen:

b select_items
c

b select_items onderbreekt de uitvoering de volgende keer dat die functie wordt aangeroepen. c gaat door totdat iets de uitvoering stopt. De uitvoering pauzeert bovenaan de functie.

Bekijk nu de broncode rondom je huidige positie en zet een breakpoint op de vergelijking zelf:

l

l toont de regels bij de plek waar je bent gestopt, met een pijl bij de huidige regel. Zoek de regel met item["quantity"] en noteer het nummer. Zet daar een breakpoint en ga verder:

b 42
c

Gebruik het nummer dat l je daadwerkelijk liet zien. Regelnummers hangen af van hoe je de eerdere hoofdstukken schreef; die van jou hoeven dus niet met die van iemand anders overeen te komen.

Kijk voordat je een stap zet

Je staat nu stil bij de vergelijking en hebt één item bij de hand. Vraag de twee waarden op die over dat item beslissen:

p item["quantity"]
p minimum_quantity

Beide drukken 4 af. Dit is dus het geval met gelijke waarden, dat de helptekst van de optie belooft te behouden.

Voer nu alleen die regel uit en kijk waar je terechtkomt:

n

n voert de huidige regel uit en stopt bij de volgende in deze functie. Let op waar de uitvoering heen gaat: het toevoegen wordt overgeslagen. Het item met aantal 4 viel weg bij drempelwaarde 4.

Dat is de hele diagnose. Het is belangrijk die precies te benoemen, want een vage diagnose leidt tot een vage reparatie. De vergelijking gebruikt >, dat gelijkheid uitsluit. De interface zegt “minstens”, dat gelijkheid insluit. Eén teken in de code is in tegenspraak met één woord in het contract.

Verlaat de debugger met q.

Repareer en controleer daarna

Open catalog.py met nano, verander de vergelijking van > in >=, sla op en voer het oorspronkelijke commando opnieuw uit:

python catalog.py catalog.csv selected.json --minimum-quantity 4
cat selected.json

Het hoort nu twee items te melden. selected.json hoort BK-101 en PN-330 te bevatten, in die volgorde.

Wees eerlijk over wat je zojuist hebt bewezen. Je reproduceerde één geval, vond de verantwoordelijke expressie en zag hoe de oplossing dat geval veranderde. Je bewees niet dat de rest van het programma correct is of dat een toekomstige bewerking dit niet ongedaan maakt. Dat zijn wezenlijke beweringen waarvoor je tests nodig hebt in plaats van een debugger. Hoofdstuk 10 gaat over het schrijven daarvan.

Haal het hulpmiddel weer weg

Een breakpoint is tijdelijk gereedschap. Het hoort bij een onderzoek, niet in het bestand dat je aan iemand anders geeft.

Als je in catalog.py hebt geëxperimenteerd met breakpoint() of pdb.set_trace(), verwijder dat dan voordat je inlevert. Anders stopt een gewone gebruiker in een debuggerprompt waar die niet om vroeg en misschien niet uit weet te komen.

Klik op Check my work zodra het gerepareerde commando en selected.json overeenkomen.

Als het aantal nog niet klopt, voer dan bij het breakpoint opnieuw p minimum_quantity uit. Vraag Monty het verschil tussen > en >= op een grens uit te leggen als het geval met gelijke waarden nog lastig voelt.