Testing your functions

What you will be able to do

After this lesson you can

• write a table of test cases for a function,
• run all the cases with a loop and read PASS and FAIL,
• choose the cases that are most likely to find a fault, and
• document a function with a docstring.

Why test a function?

You write a function once, and then you trust it in many places. A fault in a function is a fault everywhere. So a function deserves a test. A test is a set of calls with answers that you know before you run them.

You did this in the chapter on decisions with a table of marks. A function makes it neater: the test calls the function, and the function does the work.

A table of cases, and a loop

To see the test work, break the function: change mark >= 75 to mark > 75 and run again. The line for 75 now says FAIL 75 expected B got C. The test found the fault in one second, and it also shows exactly which input went wrong.

Which cases to choose

You cannot test every number. Choose well.

• An ordinary case in each branch. One for A, one for B, one for C, one for D.
• The edges, on both sides. For the edge at 75: 74 and 75. For the edge at 90: 89 and 90. Mistakes between > and >= live here.
• The smallest and the biggest allowed input. 0 and 100.
• An unusual case. An empty text, a negative number, zero, the same value twice.

Eight to twelve cases usually find most faults.

The expected answers come from the rule, not from the function. That is why a wrong function cannot pass them.

When a test fails

1. Read the line: it says which input, what you expected, and what you got.
2. Check your expected answer from the rules. A test can be wrong too.
3. Follow the function by hand for that input, like a trace table. Write the value of each variable and the result of each condition.
4. Fix one thing, and run all the tests again, not only the one that failed. A fix can break another case.

A note for the reader: the docstring

A function should say what it does. The usual way is a short note in triple quotes as the first line of the body. It is called a docstring.

A good docstring says what the function gives, in one sentence, and mentions any surprising input. You do not explain how: the code shows that.

Common mistakes

• Working out the expected answer by running the function. If it is wrong, so is your test.
• Testing only the easy values. Test the edges.
• Fixing the function and running only the failed case.
• No test at all, because "it looks right".
• A docstring that only repeats the name, such as the single word area, tells nothing.

Practice

Start with two quick questions. Each New numbers gives you a fresh one, so you can practise as long as you like.

Then the labs and the problems:

1. Warm-up. Open the lab Test the grade function. A function has a fault. Find it with the test, and fix it.
2. Build. Open the problem Test table for a function and write the cases for a ticket price function.
3. Stretch. Open the problem A temperature function and write at least six cases for it, including a negative temperature.

Remember these

• A test is a table of inputs and the expected answers, worked out from the rules.
• A loop that prints PASS or FAIL runs all the cases.
• Test one case in each branch, both sides of every edge, and the extremes.
• When a test fails, follow the function by hand. Then run all the tests again.
• A docstring says what the function gives.

Check yourself

Try each one on your own first. If you are stuck, open a hint. Then check with Show the answer.

1. Which inputs test the edge at 50 of the grade function?

2. Why do we work out the expected answers from the rules?

3. After you fix a fault, which tests do you run?