Science / Grade 10
Test input boundaries
Learning goal: Use an explicit type and range contract to check endpoints, detect strict-comparison mistakes and distinguish evidence from proof.
Before you start: Compare whole numbers and read inclusive and strict inequalities. The lesson defines explicit classroom type tags with no automatic conversion.
Read or print this lesson What to practiceThe video could not load. The transcript is still available below.
Next: your worksheet
Programming Basics: Test the Edges
Checking sign-in...
Read the transcript
Saved reading place
Video transcript and practice. Reading or printing does not count as playback time or an assessed grade.
1. Start with the requirement
Video: 0:00
Our pretend level selector accepts values tagged as integers from two through six, including both ends. All other inputs must be rejected. Write that requirement before testing an implementation. The expected result comes from the requirement, not from whatever the current program happens to do. This is a classroom model with explicitly labeled types and no automatic conversion. It does not promise that every programming language represents types in exactly the same way.
2. Try the edges and their neighbors
Video: 0:36
Choose integer one just below the range, two at its lower end, four inside it, six at its upper end and seven just above it. Their expected results are reject, accept, accept, accept and reject. Testing four alone would miss both boundaries. The door to the range includes its endpoints; it does not let the neighboring numbers sneak in with a convincing hat. Keep the expected results beside the inputs so a mismatch is visible.
3. Check type as well as value
Video: 1:08
Our requirement checks the type too. A value tagged Integer with value four is accepted. Text containing the digit four is rejected. A value tagged Decimal, written four point zero, is also rejected under this stated contract, even though it has the same mathematical value. Boolean true and a missing value are rejected as well. A different application could choose different conversion rules, but tests must follow the requirement actually given here.
4. Expose an upper-edge mistake
Video: 1:43
Suppose the implementation correctly checks the type and lower boundary, but uses level less than six instead of less than or equal to six. Integer four passes both versions. Integer six is different: the requirement accepts it, but the mistaken version rejects it. Six is a useful test because it distinguishes these two rules. A failed test tells us where the observed result disagrees with the contract; it does not change the contract to match the mistake.
5. Pause: find the missing endpoint
Video: 2:18
Try a fresh contract: accept integers from three through seven, including both endpoints. A candidate checks the Integer tag, level greater than three and level less than or equal to seven. Pause and predict its results for integers two, three, five, seven and eight. Compare each with the new requirement. Which input exposes a mistake? Decide which comparison must change. Do not reuse the previous upper-edge answer; this candidate has a different error.
6. Check the lower endpoint
Video: 2:53
Integer three exposes the error. It is inside the inclusive required range, but greater than three is false. Replace that comparison with greater than or equal to three. The corrected expected results for two, three, five, seven and eight are reject, accept, accept, accept and reject. The original candidate already handled the other four inputs in this small set. Keep the new endpoint test when checking the repair, and rerun the earlier cases too.
7. One passing case can hide a bug
Video: 3:28
Fun fact: the correct two-through-six rule and an incorrect zero-through-eight rule both accept integer four. That one passing example cannot tell them apart. Integer zero or integer eight does distinguish them. Testing deliberately chosen cases gives useful evidence, but a few successful examples do not prove correctness for every possible input. A final check should include relevant types and boundaries, not just the cases that made the first attempt look good.
8. Continue to the worksheet
Video: 4:03
Continue to the worksheet below. Its accepted integer range is one through five, so derive new expected results from that requirement. Check endpoints, nearby outside values, an interior value and the text example. Identify a test that exposes its comparison mistake, then explain the limit of passing samples. This is paper reasoning, not a security audit or a complete input-validation system. No passwords, personal data, outside services or executable commands are needed.
Show your understanding
You can point, explain aloud, draw or write.
- Derive expected results from the type and range contract, including both endpoints, adjacent values and wrong types.
- Identify a boundary counterexample, repair its comparison and explain why a few passing tests are not universal proof.
Try it yourself
Pause at the fresh range three through seven. Compare expected and candidate outputs, then repair the failing endpoint.
Continue to the worksheet with its own range one through five. These classroom type tags and paper checks are not a complete validation system or security audit.
Next: your worksheet
Programming Basics: Test the Edgeshttps://s3u.com/sca70
Lesson: https://s3u.com/lessons/test-input-boundaries