Every lesson in this unit so far has shown small snippets and trusted they were correct — a habit that stops scaling the moment a program grows past a page or two. This note formalises what "trusting the code" should actually mean: testing cannot prove a program correct, only reveal that it is wrong. This is not a pessimistic detail — it is the organising fact that shapes every testing strategy that follows. This note covers the two complementary ways of choosing test cases — black-box testing, which explores paths through a function's specification without looking at its code, and glass-box testing, which explores paths through the code itself — and closes with the standard two-phase workflow (unit testing, then integration testing) that structures how a growing program's tests are organised.
Learning objectives. By the end of this note you should be able to:
- state precisely why testing can only reveal the presence of bugs, never their absence, and explain the consequence this has for how test cases should be chosen;
- construct a black-box test suite for a function by partitioning its specification's input space, including boundary conditions and aliasing;
- construct a glass-box test suite for a function using the standard rules of thumb (both branches of every
if, loop-zero/-once/-many-times cases, both ways awhileloop can exit); - explain why unit testing should precede integration testing, and why bottom-up integration testing is generally preferred to top-down.
In this lesson
- Testing can only find bugs, never prove their absence
- Black-box testing: paths through the specification
- Glass-box testing: paths through the code
- Conducting tests: unit testing before integration testing
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.