← IGCSE Computer Science Paper 2

Why decomposition helps: testing each part separately

Each sub-problem is tested on its own before being joined to the rest, so an error is traced to the part that causes it and only that part needs fixing, not the whole program.

Part of: IGCSE Computer Science 0478 — 7b Decomposition and Sub-systems — Module 13, ACARA Digital Technologies Years 9–10 — Modular and Object-Oriented Programming (JavaScript) — Module 9, QCE Digital Solutions Unit 4 — Complex Digital Data Exchange Problems and Solution Requirements — Module 102

Understanding Why decomposition helps: testing each part separately in IGCSE Computer Science Paper 2

What it does: The test of CalcTotal fails because it adds instead of multiplying, so the error is traced to this function and not the whole program. Only the faulty line in CalcTotal is corrected. The other subroutines were already tested and stay unchanged. Testing parts separately means a failing test points to the part that causes the error. Testing one subroutine before joining it to the others catches errors early and keeps them easy to locate. Decomposition does not stop errors being made, it makes them easier to find and fix. Calling a single subroutine with known inputs tests that part on its own, before it is joined to the rest of the program.

Common mistakes: The test expects the wrong answer. 2 * 3 is 6, so a correct Area function would be reported as failing. A test of one subroutine must check against the right expected value (6) so a failure really points to that part. A PROCEDURE must be closed with ENDPROCEDURE, not ENDFUNCTION. Until this part is fixed it cannot be tested on its own, and only this procedure needs correcting.

Class: _____________________ · Name: _____________________ · Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add Why decomposition helps: testing each part separately to a class →

This module's key terms are also in a printable crossword (Modules 94–106) and word search (Modules 94–118).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning

Duo

Why is it easier to find an error when a program is split into sub-problems?

The whole program must be rewritten each time so the error disappearsEach sub-problem can be tested on its own, so the error is traced to one part

Matches

Write the whole program, then test it once at the end

↓

If it fails, the error could be anywhere in the program, so it is hard to find which part causes it. Test each sub-problem on its own first.

Applying

Meanings

Term

test each sub-problem separately

Meaning

Each sub-problem is tested on its own before being joined to the rest, so an error is traced to the part that causes it and only that part needs fixing, not the whole program.

Practice

FUNCTION CalcTotal(Price : REAL, Qty : INTEGER) RETURNS REAL

Testing

Gaps

OUTPUT (5)

Check Answer

Spots

3ENDFUNCTION

4IF Area(2, 3) = 5 THEN

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy

Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games

Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print

Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

1. Why is it easier to find an error when a program is split into sub-problems?

A. The whole program must be rewritten each time so the error disappears

B. Each sub-problem can be tested on its own, so the error is traced to one part ✓

Testing parts separately means a failing test points to the part that causes the error.

2. A programmer has written a subroutine that calculates a total price. When should it be tested?

A. On its own, before it is joined to the rest of the program ✓

B. Only after the whole program is finished and joined together

Testing one subroutine before joining it to the others catches errors early and keeps them easy to locate.

3. Test results show that the calculateAverage function gives the wrong answer, but all other subroutines pass. Where should the programmer look?

A. Inside calculateAverage only ✓

B. Through every line of the whole program

A failing test points to one part, so the search is limited to that subroutine.

4. A bug is fixed inside one subroutine of a decomposed program. What needs to be rewritten?

A. The whole program from the start

B. Only that subroutine ✓

Fixing a part does not need rewriting everything, because the other parts are separate and already tested.

5. Which statement about testing a program that has NOT been decomposed is more likely to be true?

A. An error is harder to trace because it could be anywhere in one long program ✓

B. An error is easier to trace because each part has its own test

Without separate sub-problems there are no parts to test on their own, so the cause of an error is harder to locate.

Match the Pairs

OUTPUT CalcTotal(5, 2.50) → Test one function alone by calling it with sample values and checking the result against the expected total of 12.50

CALL ShowMenu() → Run one procedure on its own to check it works before the main program uses it

A failing test points to one part: if CalcTotal gives the wrong answer, the fault is inside that function only → FUNCTION CalcTotal(Qty, Price) RETURNS REAL RETURN Qty + Price ENDFUNCTION

Fixing a part does not need rewriting everything: only the faulty line in one subroutine is changed → RETURN Qty * Price

Write the whole program, then test it once at the end → If it fails, the error could be anywhere in the program, so it is hard to find which part causes it. Test each sub-problem on its own first.

CalcTotal gives a wrong answer, so rewrite the whole program from the start → Only the faulty subroutine needs fixing. The other tested parts work and do not need to be rewritten.

Key Term

test each sub-problem separately

Each sub-problem is tested on its own before being joined to the rest, so an error is traced to the part that causes it and only that part needs fixing, not the whole program.

Fill in the Blanks

1. FUNCTION Double(n : INTEGER) RETURNS INTEGER RETURN n * 2 OUTPUT Double(5)

Hint: Type the name of the function being tested on its own, before it is joined to the rest of the program

2. expected ← 10 actual ← Double(5) OUTPUT actual = expected

Hint: Type the assignment symbol that stores the test result in the variable

3. PROCEDURE ShowTotal(a, b : INTEGER) OUTPUT a + b ENDPROCEDURE

Hint: Type the keyword that starts a subroutine that does not return a value, so it can be tested alone

4. FUNCTION Add(a, b : INTEGER) RETURNS INTEGER RETURN a + b OUTPUT Add(2, 3) // expect 5

Hint: Type the arithmetic operator that makes this one part pass its test and give the expected total

5. CALL ReadMark() CALL CheckMark() // only this is fixed CALL ShowResult()

Hint: Type the keyword that runs a procedure; only the fixed part changes, the other parts stay the same

Spot the Error

Question 1

A FUNCTION Area(w, h)

B RETURN w * h

C ENDFUNCTION

D IF Area(2, 3) = 5 THEN

E OUTPUT "Area passed"

F ENDIF

Line D — The test expects the wrong answer. 2 * 3 is 6, so a correct Area function would be reported as failing. A test of one subroutine must check against the right expected value (6) so a failure really points to that part.

Question 2

A PROCEDURE ShowTotal(t)

B OUTPUT "Total: ", t

C ENDFUNCTION

D CALL ShowTotal(10)

Line C — A PROCEDURE must be closed with ENDPROCEDURE, not ENDFUNCTION. Until this part is fixed it cannot be tested on its own, and only this procedure needs correcting.

Question 3

A PROCEDURE TestAverage()

B result = Average(4, 6)

C OUTPUT "Got: ", result

D ENDPROCEDURE

Line B — Assignment in Cambridge pseudocode uses ←, not =. The test procedure must store the result of Average in result so that this one subroutine can be checked by itself.

Question 4

A // Test CalcTax on its own

B price ← 100

C tax ← CalcTax(tax)

D OUTPUT "Want 20, got ", tax

Line C — tax has no value yet, so it cannot be passed in. The test should pass price (100) to CalcTax. A wrong input makes the test meaningless and hides whether CalcTax itself works.

Question 5

A PROCEDURE Total(a, b)

B RETURN a + b

C ENDFUNCTION

D OUTPUT Total(2, 3)

Line A — Total returns a value, so it must start with FUNCTION to match ENDFUNCTION. A PROCEDURE does not return a value, so this part would fail its test. Only this one header needs fixing.

Student with a class code? Join your class →