← ACARA Digital Technologies Years 9–10

Writing test cases before the code

Write test cases and expected results from the requirements before coding, so they check what the program should do, not what your code does. Rerun them as it grows.

Part of: ACARA Digital Technologies Years 9–10 — Testing and Validating Programs — Module 53, WA Computer Science ATAR Year 11 — Modular Programming — Module 58

Understanding Writing test cases before the code in ACARA Digital Technologies Years 9–10

What it does: The expected value is worked out from the stated discount rule, so it does not depend on the code you wrote. The loop runs all saved test cases against the function each time, so old features are rechecked after every new change. Test cases written from the requirements check what the program should do. Waiting until the code is finished makes it tempting to copy whatever the code outputs. The expected result comes from the requirement (12 is under 13, so it is rejected), not from running the program. The tests will always pass, but that proves nothing. A wrong answer in the code becomes a wrong 'expected' result.

Common mistakes: The expected value must come from the requirement. A 10% discount on 200 gives 180, not 200. The test should read assert price(200) == 180. The rule says age 13 or over is allowed, so the boundary value 13 must expect True. The test should be (13, True).

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 Writing test cases before the code to a class →

This module's key terms are also in a printable crossword (Modules 591–622) and word search (Modules 536–622).

Take this worksheet further — free with Cloodit

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

Learning
Duo
When is the best time to write your test cases and expected results?
After the code works, using what it printsBefore you write the code, using the requirements
Matches
expected = total(5) # copied from my code's output
↓
The expected result was taken from the code's own output, so the test only confirms what the code does, even if it is wrong.
Applying
Meanings
Term
test first
Meaning
Write test cases and expected results from the requirements before coding, so they check what the program should do, not what your code does. Rerun them as it grows.
Practice
tests = [(49, "Fail"), (50, "Pass"), (80, "Pass")]
Testing
Gaps
passed(50) == True
Check Answer
Spots
2assert price(50) == 50
3assert price(200) == 200

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

The 'Ostrich' badge — Full Sprint, one of Cloodit's 106 collectible badges
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. When is the best time to write your test cases and expected results?
A. After the code works, using what it prints
B. Before you write the code, using the requirements ✓
Test cases written from the requirements check what the program should do. Waiting until the code is finished makes it tempting to copy whatever the code outputs.
2. Requirement: 'Students aged 13 to 18 can join.' Which test case could you write before any code exists?
A. Input 12, expected output: rejected ✓
B. Input 12, expected output: whatever the program prints
The expected result comes from the requirement (12 is under 13, so it is rejected), not from running the program.
3. Which is the better source for an expected result?
A. The requirements ✓
B. The program's actual output
If you copy the actual output, a bug will look like a correct answer. The requirements tell you what the output should be.
4. A student writes the code first, runs it, then records the output as the 'expected' result. What is the problem?
A. There is no problem because the tests will always pass
B. The test only checks what the code does, so bugs can pass ✓
The tests will always pass, but that proves nothing. A wrong answer in the code becomes a wrong 'expected' result.
5. Requirement: 'Give 10% off orders of $100 or more.' Which expected result is written correctly from the requirement?
A. Input 100, expected output 90 ✓
B. Input 100, expected output 100 because the code uses > 100
The requirement says $100 or more gets the discount, so 90 is expected. The second answer copies a bug from the code (> instead of >=).

Match the Pairs

assert grade(50) == "Pass" → A test written from the requirement '50 or more is a Pass', ready before grade() exists
tests = [(49, "Fail"), (50, "Pass")] → A list of inputs and expected results written first, to be rerun each time the code grows
Write the expected output from the requirement, not from what your code prints → expected = 100 - 100 * 0.1 # 10% discount rule
Rerun every test as the code grows to catch anything a new change breaks → for inp, exp in tests: print(f(inp) == exp)
expected = total(5) # copied from my code's output → The expected result was taken from the code's own output, so the test only confirms what the code does, even if it is wrong.
def grade(m): ... # write code, then think of tests later → Tests were left until after the code was written, so they are likely to be shaped around the code instead of the requirements.

Key Term

test first
Write test cases and expected results from the requirements before coding, so they check what the program should do, not what your code does. Rerun them as it grows.

Fill in the Blanks

1. # Req: pass mark is 50 or more assert passed(50) == True
Hint: Type the keyword that checks a test condition and raises an error if it is false.
2. # Req: 49 fails assert passed(49) == False
Hint: Type the operator that compares the actual result with the expected result from the requirement.
3. # Req: 50 or more passes assert passed(50) == True
Hint: Type the name of the function that the test is checking.
4. # Req: 50 or more passes def passed(mark): return mark >= 50
Hint: Type the keyword that starts a function definition, written after the tests were planned from the requirement.
5. tests = [(50, True), (49, False)] for mark, expected in tests: print(passed(mark) == expected)
Hint: Type the name of the list holding the saved test cases so they can be rerun as the code grows.

Spot the Error

Question 1
A # Rule: 10% off from 100 up
B assert price(50) == 50
C assert price(200) == 200
D assert price(100) == 90
Line C — The expected value must come from the requirement. A 10% discount on 200 gives 180, not 200. The test should read assert price(200) == 180.
Question 2
A # Rule: allowed if age >= 13
B tests = [(12, False),
C (13, False),
D (30, True)]
Line C — The rule says age 13 or over is allowed, so the boundary value 13 must expect True. The test should be (13, True).
Question 3
A tests = [(49, 'F'), (50, 'P')]
B for mark, want in tests:
C if grade(mark) == mark:
D print('PASS')
E else:
F print('FAIL')
Line C — The result must be compared with the expected value want, which was written from the requirements. Comparing it with the input mark makes the test meaningless. It should be if grade(mark) == want:.
Question 4
A expected = 4 + 5 # area
B actual = area(4, 5)
C print('Expected', expected)
D print('Actual', actual)
Line A — The requirement says area is width times height, so the expected result for 4 and 5 is 20. Adding gives 9, which is wrong. It should be expected = 4 * 5.
Question 5
A def run_tests():
B assert total([2, 3]) == 5
C assert total([]) == 0
D run_test()
E print('Tests passed')
Line D — The function is called run_tests, so run_test() causes a NameError and the tests never run. The tests need to run every time the code grows. It should be run_tests().

Student with a class code? Join your class →