3.2.3 - Formative project skills: designing test data

Define a test from a requirement and expected result

A test case specifies the starting state, action/input and expected outcome for a particular requirement. Its test data are the values and records used in that case. An expected result must be derived from the requirement before running the implementation; copying the program's answer afterwards cannot expose an incorrect answer.

Consider a formative parcel-desk prototype. A parcel mass is entered as an integer number of grams from 100 to 2000 inclusive. Empty, non-integer and out-of-range entries must be rejected with an explanation, and rejection must create no parcel record. This is a deliberately limited practice rule, not a complete delivery system.

The expected outcome includes state, not just a message. “Invalid” on screen while a record is still added violates the requirement. Exact message wording is relevant only if the requirement specifies it; otherwise check its meaning. A test reference connects a planned case, its later execution and the requirement it investigates.

Control the starting state so results are interpretable. If the collection already has records, check the relevant count or identifier before and after, not an assumed empty state. Reset an isolated practice fixture deliberately between cases when needed; never erase real learner or user data to prepare a test.

Choose normal, boundary and invalid data deliberately

Normal data represent ordinary valid operation. Boundary data investigate a limit where behaviour can change. Invalid data violate the required range, format or business rule. The categories help select evidence, but the justification is what the case can reveal; a label alone is insufficient.

For the 100–2000g parcel rule, 750 is normal valid data. Test 100 and 2000 to check that the inclusive endpoints are accepted. Test 99 and 2001 to check rejection immediately outside them. The immediately-outside cases are invalid data investigating the boundary. State their expected behaviour instead of relying on whether a particular textbook calls them “boundary” or “invalid”. Using only 1000 cannot distinguish inclusive >=100 from an incorrect strict >100 test.

Other invalid cases target a different defect. Blank text checks missing-value handling; heavy checks malformed numeric input; 150.5 checks that fractional grams are not silently rounded or truncated under this integer-input rule. These cannot be replaced by an out-of-range integer: safe conversion and range validation are different decisions.

For collections, consider zero, one and multiple records, no matching identifier and duplicate identifiers if uniqueness is required. For a capacity rule, use a state with exactly enough room and one without enough room. Choose combinations that target an interaction rather than attempting every possible input indiscriminately. A very large random list of ordinary values may miss the one branch containing a defect.

Expected invalid behaviour is usually controlled rejection, not a crash. A test plan can deliberately attempt extreme inputs, but it must identify the robustness requirement and safe environment involved. Passing selected cases gives evidence about those cases; it does not prove correctness for every input.