Practical guide
Choose test inputs by the behavior they should share
Testing every input is often impossible. Equivalence partitioning groups inputs expected to receive similar treatment, then selects examples from each group.
A partition is a hypothesis about behavior
The ISTQB glossary hosted by ASTQB describes partition-based testing using representative inputs. The useful engineering question is why members of a group should behave alike. A shared type is rarely enough: empty, malformed and valid strings may take different paths, while neighboring numbers can fall on opposite sides of a limit.
Illustrative example: a numeric port validator
| Partition | Expected behavior | Useful examples |
|---|---|---|
| Below 1 | Reject | -1, 0 |
| 1 through 65535 | Accept | 1, 443, 65535 |
| Above 65535 | Reject | 65536 |
This table describes an integer validation function. A public interface accepting text has additional cases: malformed strings and overflow during parsing. A test of the integer helper does not establish those parser behaviors. Keep the tested operation's boundary explicit.
Do not remove the invalid domain
To analyze rejection, the model must include rejected values. Declaring the entire input domain as 1 through 65535 would make “reject zero” unreachable. Distinguish the incoming domain from its valid partition. If another component guarantees validity, establish that upstream contract and test the actual boundary. A middle value such as 443 also cannot detect every mistaken comparison at 1 or 65535.
Check the model, then execute its witnesses
Proof can check supported data_constraint groups for completeness and exclusivity over the authored domain. Inspect skipped constraints and inconclusive results separately.
proof verify-properties specs/system port_validation
proof audit --check data_constraints_complete --verbose
Then execute source tests for the chosen values with exact expected outcomes. A generated witness is an input suggestion until a test drives the implementation with it. Record whether the code accepted or rejected it and whether any forbidden side effect occurred.
Refine the groups when evidence disagrees
One passing value does not prove every value in its class. If a defect distinguishes two supposedly equivalent inputs, split the partition or state the missing property. Preserve the failing example, corrected requirement and regression test. That makes the next test selection better informed instead of simply larger.
Follow the evidence
List invalid partitions before choosing the happy-path examples.
Review one input partition. Bring the public interface and its expected outcomes so we can identify useful representatives, missing invalid cases and boundary tests.