Good Learning Co.
SavannahYear 8
← Computing
ComputingYear 8 Computing: data, logic and programs30 min★★★ difficulty

Modular programs: functions, testing and debugging

Long programs are not harder because they are long. They are harder because everything touches everything. Functions cut those links.

Lesson overview

What you'll learn in this lesson

Design and develop modular programs that use procedures or functions, and test and correct them systematically

Key learning points

  • • Decomposition
  • • Parameters and return values
  • • Choosing test cases
  • • Systematic debugging

This lesson at a glance

  • 30 minutes
  • 18 parts to scroll through
  • 4 quick checks
  • Marked quiz at the end
  • Gentle pace: short sittings with pauses

Words to know

designmodularprogramsproceduresfunctions

Scroll down — the lesson carries on below

Part 1 of 18 · Discover6%
1

Watch & discover

Part 1 of 18

Watch first

Modular programs: functions, testing and debugging

An English teaching video on this topic from IGCSE Daily. Watch it, then scroll down for the lesson.

In a nutshell

Design and develop modular programs that use procedures or functions, and test and correct them systematically

2

What you already know

Part 2 of 18

Before we start

What you already know

You should already know sequence, selection and iteration, and how to write a loop in a text language.

3

Key words

Part 3 of 18

Key words

Words you'll need today

Function
A named block of code that does one job and can return a value.
Parameter
An input a function is given when it is called.
Return value
The result a function hands back.
Test case
An input paired with the output you expect.
Trace table
A table recording variable values line by line to find a bug.
4

Learning cycle

Part 4 of 18

Learning cycle 1 of 2

Breaking a problem into functions

A short piece of teaching, then a check to make sure it has landed.

5

Explore the idea

Part 5 of 18

Learn

Decomposition

Start from the job, not the code. A quiz program needs to load questions, ask one, mark an answer and report a score. Each of those becomes a function with a clear name and one responsibility, so a bug in marking cannot break loading.

6

Explore the idea

Part 6 of 18

Learn

Parameters and return values

A function that reaches out to global variables is only pretending to be separate. Pass what it needs as parameters and give back a result: mark(answer, correct) returning True or False can be tested on its own, at any time, without running the whole program.

7

Quick check

Part 7 of 18

Quick check

A function should ideally...

8

Reset break

Part 8 of 18

Pause

That's sitting 1 of 2 done

Stretch, get a drink, look out of the window. There is no timer and nothing is counting down — your place is saved, so you can come back in five minutes or tomorrow.

Stop here for now
9

Quick check

Part 9 of 18

Quick check

Boundary testing for a 1–10 input means trying...

10

Learning cycle

Part 10 of 18

Learning cycle 2 of 2

Testing until it earns trust

A short piece of teaching, then a check to make sure it has landed.

11

Explore the idea

Part 11 of 18

Learn

Choosing test cases

Test normal data, boundary data and erroneous data. For a mark-out-of-ten checker that means 7, then 0 and 10, then -1, 11 and the text 'seven'. Bugs cluster at boundaries, which is exactly where casual testing never looks.

12

Explore the idea

Part 12 of 18

Learn

Systematic debugging

Read the error message first — it usually names the line and the type of fault. Then trace the variables by hand, or print them, and compare with what you expected. Change one thing at a time; two simultaneous fixes hide which one worked.

13

Quick check

Part 13 of 18

Quick check

A logic error is one that...

14

Quick check

Part 14 of 18

Quick check

A trace table is used to...

15

Common mix-ups

Part 15 of 18

Common mix-ups

Things people often get wrong

  • A syntax error stops the program running; a logic error runs happily and gives the wrong answer.
  • Printing a value inside a function is not the same as returning it.
  • Testing only with data you expect proves very little.
16

Challenge round

Part 16 of 18

Game · Sort it

Which of these are true?

Drag each card into the right column. Tap a card first if dragging is fiddly.

True

Not true

17

Mastery quiz

Part 17 of 18

Marked quiz

End of lesson quiz: Modular programs: functions, testing and debugging

6 questions, marked with the reasoning shown. No timer.

  1. 1. Parameters are...

  2. 2. Decomposition means...

  3. 3. Erroneous test data is data that...

  4. 4. When debugging you should change...

  5. 5. A return value lets you...

  6. 6. Reusable code is easier when functions avoid...

18

Lesson round-up

Part 18 of 18

Lesson round-up

Ready when you are

Quiz score

Not sat

Games

Not played

Points this lesson

0

Best run

0 in a row

Luna: 0 out of 4 on the practice checks. Only if you feel up to it — one more?

Ask Luna

Do the work

Your written work for this lesson

This is the part you'd do in your book at school. Pick the pieces below, write here or on paper, and photograph anything you draw or work out.

Article

How a supermarket checkout knows the price

When a barcode is scanned, the checkout does not store the price itself. It sends the barcode number to a database and reads back a record: product name, price, whether it needs an age check. The record is the single place the price lives, so changing one row changes every till in the shop at once.

Problems come from bad data, not bad scanners. If two products share a barcode, or a price update reaches the shop overnight but the till holds an old copy in its cache, customers are charged the wrong amount. Shops check this with test transactions: scan a known item, expect a known price, record what actually happened.

Good systems also log every scan. If a customer complains, the log shows exactly which record was used and when.

Written for Good Learning Co.

Reading questions

  1. Write in your own words what the checkout sends and what it receives back.
  2. Explain one way bad data could cause a wrong price, and how logging helps find it.
  3. Design a test table with four tests for a new checkout, with expected and actual results.

  • Reading and notes

    Reading

    Read the lesson text again and note the key terms and how each one is used, in your own words — as you would for revision.

    Half a page of notes

  • Extended writing

    Writing

    Explain a real system that uses this idea — how it works, where it can go wrong, and how you would make it safer or better.

    250–350 words

  • Algorithm on paper

    Diagram

    Write your steps out as pseudocode or a flowchart before you type anything, then photograph it.

    1 flowchart or 10 lines

  • Code write-up

    Writing

    Copy your code in, then explain underneath what each part does and what you had to fix.

    Code + 5 sentences

  • Test table

    Working out

    Make a test table: what you tried, what you expected, what actually happened.

    4–6 tests

Saved as you type.

Part 1 of 18 · Watch & discover

Good Learning Co. — personalised UK curriculum learning, built around what each learner loves.