Work Through Examples by Hand

Before you ask Python for an answer, work through a few answers yourself. A hand-worked example turns a requirement into something concrete.

The quiz score starts at zero and gains one point for every True result. Here is one result list:

[True, False, True]

Trace the score one result at a time:

Write down the expected score, 2, before writing quiz_score().

Why do this first?

If the code later returns 1 or 3, you have a precise disagreement to investigate. Without an independent expected result, it is tempting to trust whatever the program prints.

Working through the score also exposes unanswered questions:

• Does an empty result list produce a score of zero?

• Does each correct answer add exactly one point?

• Can the score ever be greater than the number of results?

Those questions belong in the requirements. Discovering them before the implementation is cheaper than discovering them after several functions depend on an assumption.

Use more than one shape of example

Choose a small set with different purposes:

• a normal case;

• a zero or empty case when it is allowed;

• an important boundary;

• a case where every answer is correct or every answer is incorrect.

For the quiz score, an empty list checks the starting value. A list of all True values checks that every correct answer is counted. Each example has a job.

Keep expected results independent

Do not calculate an “expected” result by calling the function you are testing:

expected = quiz_score([True, False, True])

That only asks the same code to agree with itself.

Instead, record the result you worked out from the requirement:

expected = 2

The example is useful because it came from a separate line of reasoning. Letting a function invent its own expected result is a little like letting it grade its own homework.