Unit 2 · Programming 1 · Lesson 2.16

Testing, Edge Cases & Pseudocode Gym

Your programs work on the inputs you expected. Today: find the inputs you didn’t — the ones that break things — and write the tests that catch them. Then a 20-minute workout reading everything so far in AP Pseudocode.

Big Idea 3 — Algorithms & ProgrammingRobustness + exam notation

Before this lesson

No new reading. Bring your Decision Day calculator from 2.15 — you’re about to try to break it on purpose.

Where We Are

People→ Bits→ Programs→ Internet→ Security→ Big Data→ Impact

Still in Programs, opening Week 4. You can write programs that decide; now you make them trustworthy. Testing is the difference between code that works on your example and code that works on everyone’s.

The Hook

Ticket price for a customer aged −3? Your Decision Day calculator will happily answer. Age −3 is “under 5,” so it prints free — a confident, wrong answer to a nonsense question.

The program isn’t broken in the crash sense; it runs fine. It’s broken in the way that actually costs money: it accepts input it should have rejected. Finding those inputs before your users do is called testing, and it’s a real engineering skill, not an afterthought.

The Idea

An edge case is an input at the boundary or outside the range you expected: the zero, the negative, the empty, the enormous, the exact boundary value. Ordinary inputs test whether your code works; edge cases test whether it’s robust.

Write the test before the fix. Decide what the right behavior is for a weird input — “age −3 should print an error, not $0” — and write that down as a test first. Then change the code until the test passes. Fixing before you’ve defined “fixed” is how you go in circles.

Guarding against bad input is input validation. You already have the tool: a compound condition from 2.14. The fix for the ticket calculator is one line at the top:

Python — a validation guard

age = int(input("Age? "))
if age < 0 or age > 120:
    print("Please enter a real age.")
else:
    # ... the elif price chain goes here ...

AP Pseudocode

age ← INPUT()
IF (age < 0 OR age > 120)
{ DISPLAY("Please enter a real age.") }
ELSE
{ /* the price chain */ }

Hover or tap a line to light its twin. One or catches both the negative and the impossible-old. This is why 2.14 mattered.

Boundaries are where bugs live. The nastiest edge cases aren’t the wild ones — they’re the boundaries. Is age 12 a child or an adult in your code? Is 65 exactly a senior? Test the exact numbers where one band ends and the next begins; that’s where an < that should be <= hides.

Try It — Break the Calculator

This is the 2.15 ticket calculator with no validation. Feed it edge cases and watch it give confident, sometimes-nonsense answers. Each one is a test you should write.

age =

Edge cases:

Vocabulary

edge case Programs: An input at or beyond the boundary of what you expected — zero, negative, empty, huge, or an exact boundary value — used to test robustness.
input validation Programs: Checking that input is acceptable before acting on it, and handling it gracefully when it isn’t.
test case Programs: A specific input paired with the output you expect — written down so you can tell whether the program is correct.

Pseudocode Gym

Six read-only reps in AP Pseudocode — the notation the exam uses for many trace questions. No Python here on purpose. Trace each on paper, then pick an answer.

0 of 6 answered

Impact Check

The bugs that make the news are edge cases

A famous 1996 rocket, Ariane 5, was destroyed seconds after launch because a number got too big for the variable holding it — an overflow edge case (you met overflow in Unit 1). Spreadsheets have turned gene names into dates. Websites have charged $0.00 because a coupon drove a price negative and nobody tested for it.

None of these were exotic. They were ordinary programs meeting an input the author never tried. “It works on my example” is the most expensive sentence in software. Testing edge cases is how professionals earn the right to say “it works.”

Connections

Came from 2.15 — the calculator you built is exactly the thing you’re now learning to test and harden.

Uses 2.14 — input validation is a compound condition. The or guard is last week’s tool doing real work.

Next in 2.17 — Mini-Project 2. Your Quiz Bot needs to survive a user who types something unexpected; today’s habit is why it will.

Returns on the exam — reading pseudocode fluently and reasoning about edge cases are both tested directly. The gym above is the exact format.