Modular design and testing each part

Step 1 Warm-up recall

From M6.L3: which structure finds a value by name?

Your answer

Private: nothing you type here is sent or stored.

Step 2 Learning goal

By the end of this lesson you can:

• combine functions into a design (Foundation);
• test a function on its own (Core);
• trace the whole design (Core).

Step 3 A familiar example

A builder checks each beam before the roof goes on. A programmer tests each function before the whole is built, because a fault is far easier to find in a small part.

Step 4 Clear explanation

A modular design builds a solution from separate functions with clear interfaces: the interface is what a function needs and what it gives back, and the inside can change without breaking the rest. Here are three invented functions for the receipt task.

The third function calls the first two: grand_total adds up the prices (40), finds the tax (10 percent of 40 is 4) and adds them to give 44. To test, check each function alone against a case you worked out by hand, including a boundary case such as an empty list of prices. Then test the whole. If grand_total fails but total_of and tax_on pass, the fault is in how they are combined. This is far quicker than hunting through everything at once. The same practice is used in every programming language.

Step 5 Worked example (4 marks)

Prices are 10, 15 and 25 and the invented tax rate is 10 percent. Find grand_total.

1. total_of: 10 + 15 + 25 = 50. (1 mark)
2. tax_on: 10 percent of 50 is 5. (1 mark)
3. Add: 50 + 5 = 55. (1 mark)
4. Answer: 55. (1 mark)

Step 6 Learner practice (instant-marked)

Step 7 Recap

• Build from functions with clear interfaces.
• Test each function alone against hand-worked cases.
• Then test the combination.

Step 8 Exit ticket (ungraded)

Work out grand_total for prices 5 and 15 with 10 percent tax.

Your answer

Private: nothing you type here is sent or stored.

Step 9 Go further (Extension)

Add an empty-list boundary case to the tests and say what total_of should return.