Trying unusual inputs
A program should cope with more than the example its author happened to try. Unusual inputs help you discover assumptions: things your program expects even though you have not written down the rule.
Try a missing answer, the smallest allowed number, the largest allowed number, or the same choice twice. These are often called edge cases or boundary cases.
Check the ends of a rule
Imagine a game that accepts levels from 1 through 5. Level 1 and level 5 should work. Levels 0 and 6 should not. Checking only level 3 tells you little about the ends.
For a nickname rule, decide whether an empty nickname is acceptable and how long it may be. Different programs can make different choices; the important part is to make the rule clear.
Test a nickname rule
Here, valid nicknames have between one and eight counted characters. The list contains pretend inputs, so the example needs no interactive host.
# language: en
for nickname in ["", "Pli", "12345678", "123456789"]:
let size = length(nickname)
if size >= 1 and size <= 8:
say "Accepted"
else:
say "Choose 1 to 8 characters."
Predict, then run
Which four answers should appear, in order?
Choose 1 to 8 characters.
Accepted
Accepted
Choose 1 to 8 characters.
The eight-character case checks whether we accidentally used < 8 instead of <= 8. Pliro’s length counts Unicode code points in text; some visible symbols, including some emoji, contain more than one. Start with ordinary letters and digits for this exercise.
Your challenge
Add a one-character nickname and repeat "Pli" twice. Should the repeats be accepted? Our rule checks length only; it does not require unique names. Now try a single space and explain why this version accepts it.
A common mistake
Expecting the program to apply an unwritten rule leads to surprises. “Not empty,” “not all spaces,” and “not already used” are different checks. Decide which ones your project actually needs before implementing them.