Test cases, assertions and useful documentation

≈ 45 min

Test cases, assertions and useful documentation

Testing is evidence, not a ceremony at the end of coding. A useful test names an input, the expected result and the reason that case matters. Normal cases show ordinary behaviour, boundary cases reveal off-by-one errors, and invalid cases check whether the program protects its contract. An assertion compares an observed result with the expected result so a failure is visible.

Documentation is useful when it helps another person make a safe decision: what a method does, what inputs it accepts, what it returns, what it changes and what can go wrong. Comments that merely repeat code waste attention. A test suite and a concise contract are better maintenance tools than a long paragraph explaining obvious syntax.

Worked reasoning. For isPass(mark), use 49, 50 and 51 rather than only 72. The values on either side of the threshold reveal whether the comparison is >= rather than >. Add an invalid case such as -1 if the method contract says marks must be between 0 and 100. Record the expected result before running the method.

Exam lens. For each proposed test, state the category and expected output. Marks often reward the justification for a boundary value, not only the value itself.

Which statement is the most defensible principle for Test cases, assertions and useful documentation?

Tests should target normal, boundary and invalid cases; documentation should explain purpose, assumptions and observable behaviour.

Treat an implementation detail as more important than the stated rule.

Assume one successful run proves the system is correct in every case.

Avoid recording assumptions, limits or failure conditions.

Enter the key term for Test cases, assertions and useful documentation. What kind of test checks the edge of an allowed range?

A method allows ages from 13 to 18 inclusive. Which set best checks both edges and just outside them?

Test 12, 13, 18 and 19 so the inclusive lower and upper boundaries are exercised.

Use a larger class or broader permission without stating a rule.

Trust the first output and skip a boundary or failure check.

Hide the decision so affected people cannot inspect it.

Name the concise safeguard or principle that completes this lesson’s scenario: A method allows ages from 13 to 18 inclusive. Which set best checks both edges and just outside them?