Testing Strategies: Black-Box and Glass-Box Testing closed with an uncomfortable inevitability: testing finds bugs, it does not fix them. Debugging is the systematic process that takes a test failure — a symptom — and narrows it down to the specific line of code responsible — the fault. This note treats debugging not as a mysterious skill some programmers just have, but as a learnable, repeatable search process: form a hypothesis consistent with all available evidence, design an experiment that could refute it, and use bisection search over the code itself — literally the same divide-and-conquer idea from Bisection Search and the Perils of Floats — to narrow a bug's location systematically rather than guessing.
Learning objectives. By the end of this note you should be able to:
- classify a bug along the overt/covert and persistent/intermittent dimensions, and explain why covert bugs are the most dangerous category regardless of how often they occur;
- follow the debugging workflow: study the data, form a falsifiable hypothesis, design a repeatable experiment, and keep a record of what has been tried;
- apply bisection search to a piece of buggy code — inserting print statements at a midpoint to decide which half of the code contains the fault, then repeating;
- recognise the vault's short list of "usual suspects" (argument order, floating-point equality, aliasing, forgetting
()) and connect at least one to a bug type already met in this unit.
In this lesson
- Classifying bugs
- The debugging workflow
- Worked example: bisecting a buggy palindrome checker
- When the going gets tough
- After finding "the" bug
Before you start
The full lesson, with worked examples and exercise solutions, is for members.
Read the full lessonNew to SelfMadeQuant.com? See membership options or browse the Python for Quantitative Finance syllabus.