Property-based testing by hand: random inputs and a rule
The seed makes the 'random' lists the same every run. Change random.seed(7) to another number and see whether a different input finds the bug.
Coverage shows which lines your tests never ran, test-driven development (red, green, refactor) writes the test before the code, and property-based testing lets a tool invent hundreds of inputs to break a rule you state. Together they find bugs your hand-picked examples miss.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write a function clamp(value, low, high) using TDD: first the table of cases (below, inside, above, equal to the limits), then the implementation. Print which cases pass.
Write a property test by hand (seeded random) that checks reversed_twice(x) == x for 100 random lists using list(reversed(list(reversed(x)))).
Use sys.settrace as in the example to show that a function with an if has a line that a single call never reaches.
Explain it without notes
What does code coverage measure, and what does it not tell you?
What is the difference between line coverage and branch coverage?
Describe red, green, refactor and why you watch the test fail first.
What is property-based testing, and what is shrinking?
Give three useful kinds of properties and an example of each.
Expected output
example test passed
property broken after 2 tries: length changed
input: [0, 0, 4, 0, 2]
output: [0, 2, 4]