← Back to course
Intro to CS 9-10 / Week 08 / Monday
1/6
Week 08 · Test, Debug, Document

Monday

It worked once
// Test plans, four kinds of errors, and guides that help others fix problems
⏱ about 20 min

Monday: It Worked Once

Comet finishes Beacon's water alert and runs it by hand on one reading: 50. No alert appears, which is correct.

"It works!" she says. "Ship it to mission control."

Wren reads the requirement aloud. "Show an alert when the water level is below 30." He looks up. "What do you notice?"

"It worked," Comet says. "For one reading."

Nova hovers beside the code and dims every number except 0, 30 and 100. "Would you like a hint?" she asks. "Try the edges."

Comet sighs, then grabs a pencil. "Fine. Let's build a real test plan."

Wren slides the requirement across to you. "You are the developer. What should we test first?"

Testing with a plan

This week asks: how do we know a program really works, and how do we help others fix it?

Testing uses defined inputs to check that an algorithm or program produces the expected outcomes.

Programmers use the test results to revise their algorithms or programs.

A program needs to work for a variety of inputs and situations, not just one. The program requirements tell you which inputs to test.

Beacon requirements
Requirement 1: Show "The tomatoes need water" when the water level is below 30.
Requirement 2: Readings run from 0 to 100. Show "Check the sensor" for any reading outside that range.
BEACON ALERT, VERSION 1
IF (waterLevel ≤ 30)
{
   DISPLAY("The tomatoes need water")
}

Test at the edges

Good test inputs show the different expected outcomes. They sit at or just beyond the extremes: the minimum and the maximum.

Beacon's readings run from 0 to 100. So the test plan includes 0 and 100, and also -1 and 101, just beyond them.

The crew also tests right at the alert line, 29 and 30, where the outcome should change.

Test inputWhy test itExpected outcome
-1Just below the minimumCheck the sensor
0The minimumThe tomatoes need water
29Just below the alert lineThe tomatoes need water
30Right at the alert lineNo message
50A middle valueNo message
100The maximumNo message
101Just beyond the maximumCheck the sensor
RUN VERSION 1 BY HAND
  • Read the question.
  • Tap your answer.
Input 50. Is 50 at most 30? What does version 1 display?
Input 30. Is 30 at most 30? What does version 1 display?
Input 101. What does version 1 display?
Which test input found the mistake in the alert line?
StatementTrue or false?
One passing test proves a program works.?
Good test inputs include values at and just beyond the minimum and maximum.?
Requirements help you choose which inputs to test.?
You should write the expected outcome after you see what the program does.?
WHY THIS EXERCISEA test is only useful when its expected outcome comes from the requirements, not from the program itself.
PUT THE TESTING PROCESS IN ORDER
  • ?Read the program requirements.
  • ?Choose test inputs, including the edges.
  • ?Revise the program, then run every test again.
  • ?Compare the actual outcome with the expected outcome.
  • ?Run the program on each input.
  • ?Write the expected outcome for each input.
WHY THIS EXERCISETesting is a planned, repeating process, not one quick try.
Testing uses defined ____ to check that a program produces the expected outcomes.
Comet only tried one reading. Wren wants the program to work for a ____ of inputs.
For a grown-up
This week, your student tests and debugs Beacon's pseudocode on paper and writes a troubleshooting guide.
Everything is unplugged. No lesson asks your student to open an app, a website or an AI tool.
On paper, draw a number line from -1 to 101. Mark each test input from the plan, and shade the part where the alert should show.

Good testing, developer. Tomorrow you will meet four kinds of bugs.