DoAssignment.ca

DoAssignment study guide

B3.4 · Validate a program with test cases

Learn to validate a program with test cases through clear examples and targeted practice.

Ontario Grade 10 Computer Science

Introduction to Programming

ICS2O study topic B3.4

A program can look reasonable and still give an unexpected result for some input. Validation means checking a program with carefully chosen test cases. A test case states an input and the output you expect for that input. You can then follow the program’s steps and compare the result with your expectation. This lesson uses input, process and output: the input is the information supplied, the process is what the program does with it, and the output is the result it displays. The examples show Python 3, but classroom languages can differ. The code is shown as text and has not been run.

What you will learn

  • Explain how test cases help check whether a program behaves as expected.
  • Choose inputs that check typical values and important boundaries.
  • Compare a program’s expected output with its output for a test input.

What a test case tells you

Suppose a school club is checking a small program that calculates the cost of an order. The input might be the order amount, the process might apply a rule, and the output might be the cost shown to the user. To validate the program, write down an input and decide what output should follow from the rule.
A useful test case is specific. “Try an amount” is not enough: write the actual amount and the expected result. You can trace the program by following its instructions using that input. The resulting value is the output predicted by the code. Compare it with the expected output based on the intended rule. A mismatch is a reason to inspect the program or the expectation.
  • A test case pairs a particular input with an expected output.
  • Trace the instructions for the chosen input; do not guess what the program does.
  • Validation checks selected cases. It does not prove that every possible input will work.

Choose useful inputs

Testing one ordinary input is a helpful start, but it may not reveal a mistake near a decision boundary. If a rule changes at 30, include an input just below 30 and an input equal to 30. The equality case matters because the program might use “at least 30” or “greater than 30”; these rules differ at exactly 30.
Choose values that relate directly to the program’s rule. A typical value checks ordinary behaviour. A boundary value checks where the result may change. If the task allows a particular minimum or maximum, a test at that limit can help check that the program treats it as intended. Always state the expected output before tracing the code.
  • Test the value at a decision boundary, not only values on either side.
  • Use the written rule to determine the expected output.
  • A test case is useful when it checks a specific part of the program’s behaviour.

Trace and compare

For each case, record the input, follow the relevant program steps, and write the output the code would produce. Then compare that traced output with the expected output. If they differ, recheck both the program’s instructions and your interpretation of the rule.
Keep the comparison honest: a hand trace is a prediction from reading the code, not a claim that the code was executed. The examples below use small programs so you can follow each step yourself.
  • Separate the expected result from the result predicted by tracing the code.
  • A mismatch identifies a case that needs attention; it does not by itself say where the mistake is.

Practise the validation routine

For a new program, first describe its purpose in plain language. Identify its input, process and output. Next, choose a small set of test cases that cover an ordinary situation and any important decision boundary. For each case, write the expected output, trace the program, and compare the two.
A simple record can use three columns: input, expected output and output predicted by tracing. Add a note if they match or differ. This makes your reasoning visible and helps another person check the same case. Do not add unrelated inputs simply to make the list longer; select cases that check the stated behaviour.
  • Plan cases from the program’s intended behaviour.
  • Record expectations before tracing so they are an independent comparison.
  • Use the results to decide what needs further checking.

Test-case trace for delivery fee

Input amountExpected feeOutput predicted by tracingMatch?
2555Yes
3955Yes
4000Yes
5200Yes

Worked example

Checking a simple calculation

A program should display twice the whole number entered. Validate it with input 6 and input 0. For each case, state the expected output and trace the calculation.
Double the input
Input numberMultiply by 2Display result

Input a whole number, multiply by 2, and display the result.

Python 3

number = int(input())
result = number * 2
print(result)
  1. Identify the parts
    The input is a whole number. The process multiplies that number by 2. The output is the displayed result. The intended rule determines the expected output for each test.
  2. Trace both cases
    For input 6, the process gives 12, which matches the expected output. For input 0, the process gives 0, which also matches. These cases check an ordinary positive input and zero.
Answer: The test cases are input 6 with expected output 12, and input 0 with expected output 0. Tracing the displayed code predicts those outputs.
Check: The zero case is useful because it checks that the calculation handles zero as intended.

Worked example

Testing a decision at its boundary

A club calls an activity “long” when its duration is at least 30 minutes; otherwise, it calls it “short.” Test 29, 30 and 31 minutes.
Classify an activity duration
YesNoInput minutesMinutes >= 30?Display LongDisplay Short

The Yes and No paths show the outputs for the decision.

Python 3

minutes = int(input())
if minutes >= 30:
    print("Long")
else:
    print("Short")
  1. Set expected outputs
    The rule says 30 minutes or more is long. Therefore 29 is expected to be short, while 30 and 31 are expected to be long. The case at exactly 30 checks the equality boundary.
  2. Trace the decision
    For 29, the condition minutes >= 30 is false, so the program takes the No path and prints Short. For 30 and 31, the condition is true, so each takes the Yes path and prints Long.
Answer: Expected outputs: 29 gives Short; 30 gives Long; 31 gives Long. Tracing the condition predicts the same results.
Check: If the condition were written as minutes > 30, the case 30 would take the No path and expose a boundary error.

Worked example

Checking a free-delivery rule

A shop’s practice program should charge a delivery fee of 5 for orders below 40, and no delivery fee for orders of 40 or more. Test order amounts 25, 39, 40 and 52. Treat these as example amounts, not real prices.
Choose the delivery fee
YesNoInput amountAmount >= 40?Display fee 0Display fee 5

An order of 40 or more has no delivery fee in this example.

Python 3

amount = int(input())
if amount >= 40:
    print(0)
else:
    print(5)
  1. Choose cases from the rule
    The inputs 25 and 52 check an amount below and above the threshold. The inputs 39 and 40 check the values immediately around the change, including equality at 40.
  2. Trace and compare
    For 25 and 39, the condition amount >= 40 is false, so the program displays a fee of 5. For 40 and 52, it is true, so the program displays 0. Each traced result agrees with the expected result from the stated rule.
Answer: Expected and traced fees are 25 → 5, 39 → 5, 40 → 0 and 52 → 0. The cases at 39 and 40 check the threshold closely.
Check: This program displays the fee only; it does not calculate a full order total.

Common mistakes and how to avoid them

Testing only one ordinary input.
Correction: Include a case at an important decision boundary, because the program’s result may change there.
Writing down only the input and not the expected output.
Correction: Decide what the program should display from its stated rule before tracing the code.
Treating a hand trace as proof that code was run.
Correction: Describe it as an output predicted by following the instructions. Do not claim execution when none occurred.
Assuming that matching test cases guarantee the program is correct for every possible input.
Correction: Say that the selected cases matched. A finite set of checks does not cover every possible input.

Lesson summary

  • Validation uses test cases to check whether a program behaves as expected.
  • A test case includes a particular input and its expected output.
  • Trace the program for that input and compare the predicted output with the expectation.
  • Include useful ordinary and boundary cases, especially when a decision changes at a threshold.

Check your understanding

Question 1

A program displays “Open” when a shop’s closing time is 18 or later, and “Closed” otherwise. Which input is the most direct test of the equality boundary?
  1. 17
  2. 18
  3. 25
  4. 10
Show answer and explanation
18
The rule changes at 18, so input 18 directly checks whether equality is included.

Question 2

A program is intended to display the input number plus 4. For input 3, what expected output should you write before tracing the program?
  1. 3
  2. 4
  3. 7
  4. 12
Show answer and explanation
7
The stated process adds 4 to the input, so 3 leads to an expected output of 7.

Question 3

Two selected test cases match their expected outputs. What can you conclude?
  1. The program must work for every possible input.
  2. The program matches expectations for those two cases.
  3. The expected outputs must be wrong.
  4. No more test cases can be useful.
Show answer and explanation
The program matches expectations for those two cases.
Matching cases provide evidence about those inputs only; they do not establish behaviour for every possible input.

Key terms

Input
Information supplied to a program.
Process
The work a program does with its input.
Output
Information or a result the program displays.
Test case
A particular input together with the output expected for that input.
Boundary
A value where a program’s decision or result may change.
Trace
Following program instructions for a chosen input to predict the output.

Continue through ICS2O

View the complete ICS2O Ontario Grade 10 Computer Science curriculum and lessons

Tutor support for B3.4 · Validate a program with test cases

Working on B3.4 · Validate a program with test cases in ICS2O? Bring the question and your own attempt. In a live session, you can trace a small input step by step, compare expected and actual output, and test an edge case. Ask about the first step that does not make sense, then try a similar question yourself.

Explore coding tutoring · Request an eligible free 30-minute introduction. Your request is matched by subject and language; a tutor must accept before a time is confirmed.

برای مبحث B3.4 · اعتبارسنجی برنامه با موردهای آزمون در درس ICS2O، سؤال و تلاش خود را همراه بیاورید. در جلسه می‌توانید یک ورودی کوچک را گام‌به‌گام دنبال کنید، خروجی مورد انتظار و واقعی را مقایسه کنید و یک حالت مرزی را بیازمایید. راهنمای معلم برنامه‌نویسی را ببینید یا جلسهٔ معارفهٔ رایگان ۳۰ دقیقه‌ای درخواست کنید. زمان جلسه پس از پذیرش معلم قطعی می‌شود.

About this lesson and its review

Published by DoAssignment. This reviewed lesson follows Ontario Grade 10 Computer Science (ICS2O), expectation B3.4. It is a study resource, not an official curriculum publication.

Before publication, content is checked for structure, mathematical or chemical notation, calculations, course boundaries, and readability. Errors can still occur, so corrections are welcomed.

Official curriculum reference

Report a correction or ask a question