4. Boundary values and comparison mistakes

Boundary-value checks examine the edges where a rule changes. For an inclusive integer range one through three, a three-value neighborhood around each limit gives zero, one, two and two, three, four. Deduplicate the shared interior value while retaining its rationale.

The step of one comes from the discrete integer domain. Currency precision, timestamps and text length need their own defined unit and representation. Do not apply plus or minus one mechanically without understanding what adjacent means at the tested boundary.

The example pairs each value with its expected validity. A validator using greater-than instead of greater-than-or-equal at the minimum will fail the one case. A validator accepting four will fail the upper outside case. These observations distinguish mistakes that a middle value cannot reveal.

Boundary checks complement partitions. A fraction or wrong primitive may require a separate class even when all integer edges behave correctly. Describe the coverage achieved rather than claiming that five values prove the whole validator.

The weak table tests only two and concludes that both limits work. An implementation accepting only two would pass that check. This is a useful counterexample because it shows how a green test can coexist with obvious missing behavior.

Avoid generating expected validity by calling the same predicate under test. The resulting table would adapt to an incorrect comparison. Write the expected values from the contract first, then execute the implementation and compare.

Create a boundary table for an inclusive integer range ten through twenty. Include the nearest outside, exact boundary and nearest inside at both ends. Start with the lower neighborhood, then add the upper neighborhood.

State the domain unit explicitly and retain a separate fractional case if you want to test integrality. The basic task has six small rows; no property-testing framework or large random dataset is required to understand the comparison behavior.

Step 1: List nine, ten and eleven first. Step 2: Add nineteen, twenty and twenty-one with expected results.

The solution uses nine, ten, eleven, nineteen, twenty and twenty-one with explicit expectations. The local verifier runs those cases against the range validator and demonstrates that strict comparisons at either end are detected. That is stronger evidence than counting six passing assertions alone.

Review duplicate and missing boundary rows independently. A table can have the right length while repeating one value and omitting another. Use expected sets or named cases so the test plan’s structure remains understandable after edits.

In interviews, derive the neighboring values from a stated domain and explain which wrong comparison each row would expose. Mention assumptions about inclusive limits and integer units before presenting a memorized boundary list.

Next, use decision tables when several independent conditions determine an outcome. Boundary analysis answers nearby values of one dimension; it does not by itself establish correct combinations of account and permission state.

Optional stretch — after the core task works: Add an explicit decimal-amount boundary with a defined cent unit.

Computer practice: download the companion lab at https://applydjinn.com/typorithm/qa-lab-20261105.zip. Read its README, install the pinned tools and run the accepted examples before attempting a starter. The mobile reader preserves your reading and self-check progress; the local lab runs browser tests separately.