DoAssignment study guide

A4.5 · Validate a program with varied test cases

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

Ontario Grade 11 Computer Science

Programming Concepts and Skills

ICS3U study guide — expectation A4.5

A program can appear to work for one input and still give the wrong result for another. Validating a program means checking its behaviour with different inputs and comparing each result with what the program is supposed to do. A test case records an input and its expected result. The expected result comes from the program’s stated purpose, not from guessing what the code will produce. In this lesson, we will use small examples and trace the code by hand; no code is being executed here.

What you will learn

Explain what it means to validate a program with varied test cases.
Choose test inputs that check ordinary, boundary, and unusual-but-allowed situations.
Trace a short program to determine its expected output.
Compare an observed result with an expected result and use mismatches to identify a possible problem.

1. Start with the program’s purpose

Before choosing tests, state what the program should do and what inputs it accepts. This gives you a standard for judging its output. For example, if a program is meant to say whether a temperature is below freezing, clarify whether the input is a number and what should happen at exactly zero.

Think in terms of input, process, and output. The input is the value supplied to the program. The process is the rule applied to it. The output is the result that a user should see. A useful test checks whether the output matches that rule for a particular input.

A test case is not just an input. It pairs an input with an expected output. Keep that expected output separate from any result you observe when testing the program. In this lesson, we derive expected outputs by tracing; we do not report actual runs.

Write down the intended rule before judging the code.
For each test case, record the input and the expected output.
A mismatch means the program needs investigation; it does not by itself tell you exactly where the problem is.

2. Choose varied, useful cases

Varied tests check different parts of the program’s intended behaviour. Include an ordinary case that represents a typical input. Also consider boundary cases: values at or near a point where the expected result changes. If the input rules allow them, include unusual cases such as the smallest accepted value or a value that does not meet a condition.

For a rule that separates numbers below zero from numbers at or above zero, testing only a negative number is not enough. A zero input checks the boundary, and a positive input checks the other side. These cases are useful because they challenge different parts of the rule.

Only test inputs that fit the program’s stated input rules unless you are specifically checking how it handles invalid input. Do not assume a program must handle an input that its purpose or instructions exclude. If invalid input is in scope, state what response is expected before testing it.

Use cases that represent different meaningful situations, not just several similar values.
Test boundary values where the expected result may change.
Make the expected result clear for every chosen input.

3. Trace, compare, and improve the tests

Tracing means following the program’s statements in order and keeping track of the values they use. For a short program, a trace table can show the input, the value of a variable after a calculation, and the output. This helps you derive an expected result without claiming that the code has been run.

After testing, compare each observed result with its expected result. If they differ, check the intended rule, the input, and the part of the program that handles that case. A passing result for one case does not prove every possible input is correct; it only confirms that the program matched the expectation for that test.

Python 3 is used in the examples. Python syntax and indexing conventions are language-specific; a classroom using another language may express the same rule differently. The code is shown as text and is not run.

Derive expected output from the stated purpose and a careful trace.
Record expected and observed results separately when performing real tests.
Use a failed comparison to guide further checking, not to make an unsupported claim about the cause.

Expected test cases for the examples

Program purpose	Input	Expected output	Why this case helps
Below-freezing check	-4	True	Negative ordinary case
Below-freezing check	0	False	Boundary value
Below-freezing check	6	False	Positive case
Pass-mark decision	49	Not yet	Just below boundary
Pass-mark decision	50	Pass	At boundary
Pass-mark decision	100	Pass	High accepted value
Price total	[]	0	Empty list
Price total	[4]	4	One item

Trace of the price-total program for [2, 0, 5]

Value being added	Total before	Total after
2	0	2
0	2	2
5	2	7

Worked example

Testing a below-freezing check

Purpose: given a temperature in degrees Celsius, display True if it is below zero and False otherwise. The accepted input is a number. Choose varied tests and derive the expected output.

Python 3

temperature = 0
print(temperature < 0)

Choose cases
Use a negative temperature, the boundary value zero, and a positive temperature. These inputs check both possible outcomes and the point where the outcome changes.
Trace one case
For an input of zero, the comparison asks whether zero is less than zero. That statement is false, so the displayed result should be False.
Compare results
For a real test, compare the observed output for each input with the expected output in the table. A different result for any case means the program has not matched its stated purpose for that case.

Answer: Expected outputs are True for -4, False for 0, and False for 6.

Check: The zero test matters because a program using less-than and a program using less-than-or-equal would behave differently at the boundary.

Worked example

Testing a pass-mark decision

Purpose: given a whole-number mark from 0 through 100, display "Pass" for marks of 50 or more and "Not yet" for marks below 50. Choose tests that check the boundary and the range.

Python 3

mark = 50
if mark >= 50:
    print("Pass")
else:
    print("Not yet")

Select varied marks
Choose 49 and 50 to test the values immediately below and at the decision boundary. Choose 100 to check an accepted high value. The stated input range is 0 through 100.
Trace the boundary
At 50, the condition mark >= 50 is true, so the first output is selected. At 49 it is false, so the other output is selected.
Use the expected results
Record these expected outputs before comparing them with observed results from any permitted test. A result that differs signals a case to investigate.

Answer: Expected: 49 gives "Not yet"; 50 gives "Pass"; 100 gives "Pass".

Check: The test at 50 distinguishes a condition that includes the boundary from one that starts only above it.

Worked example

Testing a small total

Purpose: given a list of item prices, display their total. The list may be empty or contain zero or more non-negative prices. Choose tests that check an empty list, a single item, and multiple items.

Python 3

prices = [2, 0, 5]
total = 0
for price in prices:
    total = total + price
print(total)

Check different list sizes
An empty list checks what happens when there are no items. A one-item list checks a simple total, while a list with several values checks that each value contributes to the sum.
Trace the multi-item case
For [2, 0, 5], total starts at zero. Adding the first value makes it 2; adding zero leaves it 2; adding 5 makes it 7. The expected displayed total is 7.
Respect Python indexing
Python lists use zero-based indexes: in [2, 0, 5], index 0 holds 2, index 1 holds 0, and index 2 holds 5. This is a Python-specific detail; another classroom language may use a different convention.

Answer: Expected totals: [] gives 0, [4] gives 4, and [2, 0, 5] gives 7.

Check: The zero in the multi-item case checks that including a zero-valued item does not change the total.

Common mistakes and how to avoid them

Testing only one typical input.

Correction: Add cases that check other meaningful outcomes, especially values at a boundary and inputs with different relevant features.

Treating an expected result as though it were an observed result.

Correction: Derive the expected result from the purpose and trace. Only record an observed result after actually performing a test.

Choosing an input without deciding what its correct output should be.

Correction: Write the expected output beside each input before comparing program behaviour.

Assuming one matching test proves the whole program is correct.

Correction: A match supports the program’s behaviour for that case only. Continue with varied cases that check the intended rule.

Lesson summary

Validation checks a program’s behaviour against its stated purpose using varied test cases.
A useful test case includes an input and a clearly derived expected output.
Ordinary, boundary, and other meaningfully different accepted inputs can reveal different problems.
Trace short programs carefully, then compare observed results with expected results when tests are performed.

Check your understanding

Question 1

A program should display "Cold" below 10 and "Warm" at 10 or above. Which set best checks both sides of the boundary?

2 and 4
9 and 10
10 and 12
correctIndex` is intentionally not included here. Please ensure JSON is valid.

Show answer and explanation

9 and 10

9 is immediately below the boundary and should give Cold; 10 is at the boundary and should give Warm.

Question 2

A total program accepts an empty list. What expected output should be checked for an empty list if the total starts at zero and adds each item?

0
An error is always required
The program must ask for another list
correctIndex` is intentionally not included here. Please ensure JSON is valid.

Show answer and explanation

With no items to add, the starting total remains zero. The stated purpose accepts an empty list.

Key terms

Validate: Check whether a program behaves as intended for selected inputs.
Test case: A particular input paired with the result expected from the program’s stated purpose.
Boundary case: A test input at or near a point where the expected outcome changes.
Trace: Follow program statements in order while keeping track of relevant values.

Continue through ICS3U

View the complete ICS3U Ontario Grade 11 Computer Science curriculum and lessons

About this lesson and its review

Published by DoAssignment. This reviewed lesson follows Ontario Grade 11 Computer Science (ICS3U), expectation A4.5. 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