Equivalence partitioning: choose defensible test inputs

01 / Define the shared behavior

What makes an equivalence class useful?

A class is useful when you can explain why its members should satisfy the same relevant handling rule at a stated interface and state. For one characteristic, define nonempty, disjoint classes that cover the declared incoming domain. Give every class a concrete admissible member; an impressive predicate with no possible input cannot supply a representative.

For this field, the criterion is response category and rejection reason, or the accepted-input preservation relation. Two accepted values share the rule that the returned integer equals the supplied integer. They need not return identical numeric payloads. The selected observation matters because a bare accepted: true would miss a changed port, and a bare rejection would miss the wrong reason or response shape.

Choose the observation to fit your rule. If a request must leave stored data unchanged, acceptance category alone cannot group its required effects. If behavior depends on state or another field, include that context in the class definition. Input-space modeling can include parameters, current state and user-level inputs; the Ammann and Offutt chapter summary makes that scope explicit.

The hypothesis needing evidence is that the implementation respects the shared rule throughout each class. A selected member cannot establish that premise. Weyuker and Jeng's partition-testing analysis explains why representative reasoning depends on how fault-revealing inputs are distributed within subdomains; it supplies no effectiveness measurement for this fixture.

Equivalence partitioning organizes classes and representatives. Boundary value analysis adds witnesses near ordered edges. Requirements-based testing establishes the approved expectations; diagnosing a green suite asks whether its inputs, assertions and oracle support its claim. Here the task is to make the input selection and its assumptions reviewable.

02 / Start with the artifact

Free equivalence-partitioning worksheet

Copy this complete record for one interface and one partition characteristic. Duplicate the class and case blocks as needed. Use an approved rule, an identifiable candidate and a way to observe the required result. If any is missing, keep the record in planning status and assign the blocker.

Copy EQUIVALENCE-PARTITION RECORD
Evidence status: NOT RUN
Decision status: NOT ACCEPTED

AUTHORITY AND SCOPE
Record ID / revision:
Rule ID / revision / authoritative source:
Approved wording and exact required behavior:
Policy approver / unresolved decisions / decision due event:
Interface / callable / adapter / actual caller:
Input representation / units / relevant state and configuration:
Candidate revision or content identity:

DOMAIN AND CRITERION
Actual incoming domain, including values required to be rejected:
Valid subset of that incoming domain:
Excluded representations and behaviors / justification / owning check:
Upstream restrictions, if any / evidence they hold at this call boundary:
Characteristic being partitioned:
Shared-behavior criterion:
Observation boundary and why it distinguishes the required behavior:
Permitted differences among members, such as preserved input payload:
Modeled assumptions and exactly which domain they restrict:

CLASS BLOCK: COPY FOR EVERY PROPOSED CLASS, INCLUDING INVALID CLASSES
Class ID / valid or invalid:
Predicate over the declared domain:
Concrete admissible member / membership justification:
Required response rule and relevant effects:
Chosen representative / reason for choosing it:
Literal required observation for that representative:
Required keys / exact types / values / state changes / forbidden effects:
Why the selected member might miss another member's failure:
Additional within-class evidence needed / owner:

PARTITION REVIEW
Every class nonempty / concrete witnesses:
Pairwise overlaps / resolution:
Union covers which domain / gaps and exclusions:
Review or model method / assumptions / result / evidence status:
Other fields or states that affect the characteristic:
Required combinations / infeasible combinations and justification:
Invalid-input isolation or combined-error precedence to resolve:

SELECTION AND ORACLE
Representative set:
Ordering / endpoint inclusivity / immediate-neighbor convention:
Chosen boundary values / omitted boundaries and reason:
Deduplicated selected values or tuples:
Coverage unit / identified-class denominator / classes exercised:
Unique selected cases / repeated invocations / gate runs:
Independent oracle authority / derivation / oracle revision:

CASE BLOCK: COPY FOR EACH INPUT / SELECTION / CANDIDATE COMBINATION
Case ID / class / selection purpose / input and starting state:
Literal required response and effects before execution:
Actual response, exact types, relevant state and execution error:
Assertion result / skipped or blocked reason:
Raw record location / candidate and harness identities:

EXECUTION AND REPLAY
Source file(s) / exported function(s) / build or content hashes:
Harness / oracle source identities and actual call path:
Prerequisites / observed runtime versions / configuration:
Working directory / exact commands / output preservation rule:
Baseline failure: case, expected, actual and evidence:
Implemented correction / changed source identity:
Same-case replay plus affected selections / actual results:
Controls: deliberate wrong behavior / expected failure / observed result:
What the controls establish and what they leave untested:
Exit-code meaning / missing, empty or partial-run handling:

DISPOSITION AND FRESHNESS
Supported conclusion and its exact scope:
Remaining evidence for within-class behavior:
Unperformed interface, parser, type, overflow, state or integration work:
Rule/domain/code/adapter/oracle/harness/runtime changes that stale evidence:
Reuse assessment or rerun required / responsible reviewer:
Accountable person or queue / next action / completion or decision event:
Acceptance authority / decision / exceptions and revisit condition:

03 / An example you can reproduce

Numeric port field: strengthen the representatives without changing the rule

This is a newly implemented and executed fictional configuration-field exercise. The previous guide's numeric port table was illustrative; it supplies no historical run or production incident. The authority here is the authored contract numeric-port-field-partitions-v1 .

Establish the incoming domain

The direct-call precondition is type(port) is int, excluding bool. Negative integers, zero and values above 65535 remain incoming values and must reach the callable. Only 1 through 65535 inclusive is valid. No upstream restriction to that interval is established.

This boundary does not exercise text or bytes parsing, incoming type validation, fixed-width overflow, collection inputs or network binding. Python integers have arbitrary precision, and bool is an integer subclass, so the exact-type precondition is deliberate. Python types · Python type

Zero is rejected by this fictional field policy. That is not every network API's rule: Linux Internet-domain bind can use port zero to request an ephemeral port. Linux bind(2)

Declare the classes, then choose members

Each predicate has its displayed witness. No exact integer satisfies two predicates, and every exact integer satisfies one. That is a logical review of the stated domain, not a solver result or evidence about excluded types.

The three initial calls pass. To challenge endpoint handling, the next selection adds 0, 1, 2 around the accepted lower endpoint and 65534, 65535, 65536 around the accepted upper endpoint. Their union with the representatives contains eight distinct values: 3 + 6 - 1 = 8, because 65536 appears in both selections.

These are six chosen endpoint and neighbor values around the two accepted endpoints. They are not every invalid-class neighbor or a standard-wide boundary-coverage denominator. The three behavior classes remain unchanged; endpoint and interior positions refine the selection within them.

Read the failure and implemented correction

The baseline's actual upper comparison is port >= 65535. It rejects the valid endpoint. The corrected exported function uses port > 65535.

The source contains both functions. The harness imports them and calls the selected exported function directly. Expected whole responses come from independent literals in cases.json. Its recursive comparison requires the exact dictionary keys, field types and values, so Python's True == 1 cannot substitute for the promised type. This is an output-oracle check, not an incoming type-validation campaign.

The accept-all control fails the three selected invalid values; the reject-all control fails the five selected valid values. These two deliberate controls demonstrate sensitivity to those cases. They are not a mutation score. Across the six gates, 3 + 6 + 8 + 8 + 8 + 8 = 41 helper invocations reuse eight distinct integers.

The correction repairs the observed endpoint failure and passes the refined selection. These calls do not establish every member's behavior, defect-class closure, production correctness or certification. No Proof command, solver or property-generated campaign ran in this fixture.

Inspect the baseline failure · Inspect the corrected replay · Get the real evidence kit

Reproduce the recorded contrast

Download the kit, check its ZIP checksum, and extract it into a new directory. The archive has no enclosing directory. Use Python 3.10+ and the standard library; no packages, network service, credentials or Proof installation are needed. From the extracted directory:

Copy python3 reproduce.py

The default rerun-output/ must be absent or empty. To preserve a prior run, choose another absent or empty directory:

Copy python3 reproduce.py --output-dir another-run

Wrapper exit 0 means the expected passing and failing gates reproduced. It does not mean every implementation passed. Inspect the new raw stdout/stderr files and reproduction-summary.json; the original observations remain under observed/. Follow the actual README for directory reuse.

The primary capture used Python 3.14.7 with optimization flag 0 and debug assertions enabled. Python 3.10+ is a prerequisite, not an executed matrix. The provenance and summary retain the runtime, commands, timestamps and content hashes. A reader's replay is a separate execution.

Filled partition record

This record is complete for the frozen helper exercise. Proposed responsibilities for adopting it in a project remain visibly unassigned.

Copy EQUIVALENCE-PARTITION RECORD: FILLED TEACHING EXERCISE
Record/artifact: equivalence-partitioning-numeric-field-v1
Evidence: OBSERVED local helper calls
Decision: corrected selected gate passed; production acceptance NOT ASSESSED

AUTHORITY AND SCOPE
Rule: numeric-port-field-partitions-v1, contract.json
Authority: authored fictional field policy, not inferred from implementation.
Project policy approver: none identified; assign before adapting this rule.
Boundary: one direct exported function call with one exact Python integer.
Representation/units: integer value of the fictional port field, no conversion.
State: pure helper; no persistent state or network operation in this fixture.
Incoming D: all values satisfying type(port) is int, excluding bool.
Valid subset V: 1 <= port <= 65535.
Retained invalid inputs: integers below 1 and above 65535, including zero.
Other types: outside D, unspecified and unperformed here.
Upstream valid-only restriction: none established or assumed.

CRITERION AND PARTITION REVIEW
Characteristic: specified response handling for the integer's range.
below: port < 1
  Concrete member/representative: -1; it satisfies port < 1.
  Required literal: {"accepted": false, "reason": "too_low"}
  Rationale: samples the lower rejection rule; does not cover every member.
valid: 1 <= port <= 65535
  Concrete member/representative: 443; it is inside the accepted interval.
  Required literal: {"accepted": true, "port": 443}
  Shared rule: accepted is true and exact integer port equals the input.
  Rationale: accepted interior member; endpoint handling remains unchallenged.
above: port > 65535
  Concrete member/representative: 65536; it is immediately above the interval.
  Required literal: {"accepted": false, "reason": "too_high"}
  Rationale: samples upper rejection and is also an upper outside witness.
Shared behavior: category/reason or input-preservation relation.
Permitted difference: accepted members return their own different integers.
Relevant observation: whole response, so acceptance cannot hide changed data,
wrong reasons, wrong field types or missing/extra keys.
Nonempty: the three concrete members witness membership.
Disjoint/exhaustive: the three inequalities partition D, by logical review.
Modeled assumption: exact-int input only; no restriction to V.
Scope: this single integer characteristic; no Proof/solver result exists.
Interactions: no second field or mutable state in this helper contract.
Cross-characteristic combinations: not applicable; one characteristic,
no second field or mutable state.
Missing interface behaviors: parsing, type validation, bytes/collections,
fixed-width overflow and network operations were not exercised.

SELECTION AND INDEPENDENT LITERAL ORACLE
Representatives: -1, 443, 65536.
Ordering: integer order; accepted endpoints 1 and 65535 are inclusive.
Neighbor convention: predecessor, endpoint, successor at accepted endpoints.
Selected neighbors: 0, 1, 2 and 65534, 65535, 65536.
Omissions: not every invalid-class neighbor; no universal BVA denominator.
Refinement: keep three authored classes; strengthen endpoint/interior selection.
Union: -1, 0, 1, 2, 443, 65534, 65535, 65536.
Overlap: 65536 belongs to both selection sets; 3 + 6 - 1 = 8 unique values.
Identified-class exercise: 3 of 3 classes sampled; no all-member conclusion.

Case ID                                  Input   Literal required response
below-representative                     -1      {"accepted": false, "reason": "too_low"}
lower-outside                            0       {"accepted": false, "reason": "too_low"}
lower-at                                 1       {"accepted": true, "port": 1}
lower-inside                             2       {"accepted": true, "port": 2}
valid-representative                     443     {"accepted": true, "port": 443}
upper-inside                             65534   {"accepted": true, "port": 65534}
upper-at                                 65535   {"accepted": true, "port": 65535}
above-representative-and-upper-outside    65536   {"accepted": false, "reason": "too_high"}

Oracle: independently authored cases.json literals from contract.json.
Assertion: same_typed_structure in run_cases.py, exact dict keys and types;
accepted is bool, accepted port is exact int, rejection reason is str.
Unexpected callable exception fails the case. No extra keys are permitted.
The harness checks its input construction is exact int before calling code;
this does not establish a production type validator or upstream guarantee.

IMPLEMENTATION AND EXECUTION IDENTITY
Source: validator.py contains baseline, corrected and both control functions.
Baseline: validate_port_baseline; corrected: validate_port_corrected.
Controls: validate_port_accept_all and validate_port_reject_all.
validator.py SHA256:
87d38bff76c89416617815c691383b254f3b7b0ade64440b6ee0b0a7644b7c4d
run_cases.py SHA256:
db7a2eecdea99e3b7b565af39d3bd6e953765658fa25230e0fecd1e3a2cf9196
cases.json SHA256:
57484d2f946888ab493d39c0f79d23a46f4e25afd011a45e033309a68dbe6698
contract.json SHA256:
4aa5bc9c041bdac9887ebbd800286684cb630979fbe689892b08e5e129d67be1
Content hashes plus exported function identify each candidate; no Git
revision or separate before/after commit is claimed.
Call path: reproduce.py subprocess -> run_cases.py IMPLEMENTATIONS mapping
-> imported validator.py function(case["port"]) -> same_typed_structure.
Capture: final primary run, 2026-10-28, Python 3.14.7.
Configuration: optimize_flag 0; debug assertions enabled; children use -B -u.
Prerequisite: Python 3.10+ standard library; this is not a tested matrix.
Working directory: kit root, represented as "." in the recorded summary.

Exact recorded child commands:
/opt/homebrew/opt/python@3.14/bin/python3.14 -B -u run_cases.py --implementation baseline --selection representatives
/opt/homebrew/opt/python@3.14/bin/python3.14 -B -u run_cases.py --implementation baseline --selection six-neighbors
/opt/homebrew/opt/python@3.14/bin/python3.14 -B -u run_cases.py --implementation baseline --selection refined-eight
/opt/homebrew/opt/python@3.14/bin/python3.14 -B -u run_cases.py --implementation corrected --selection refined-eight
/opt/homebrew/opt/python@3.14/bin/python3.14 -B -u run_cases.py --implementation accept-all --selection refined-eight
/opt/homebrew/opt/python@3.14/bin/python3.14 -B -u run_cases.py --implementation reject-all --selection refined-eight

Portable replay from extracted kit: python3 reproduce.py
Preserve another run: python3 reproduce.py --output-dir another-run
The wrapper uses the current interpreter; the Homebrew path is capture identity.
Default rerun-output/ or chosen output directory must be absent or empty.
New observations stay separate from retained observed/ files.

FAILURE, IMPLEMENTED CORRECTION AND OBSERVATIONS
Failure case: upper-at, input 65535, authored class valid.
Required: {"accepted": true, "port": 65535}
Baseline actual: {"accepted": false, "reason": "too_high"}
Cause: baseline upper rejection condition is port >= 65535.
Implemented correction: corrected function uses port > 65535.
Corrected actual: {"accepted": true, "port": 65535}; same witness replayed.
The requirement and literal expectations were not changed to fit baseline.

Gate                           Passed/calls   Child exit
baseline-representatives       3/3            0
baseline-six-neighbors         5/6            1
baseline-refined-eight         7/8            1
corrected-refined-eight        8/8            0
accept-all-refined-eight       5/8            1
reject-all-refined-eight       3/8            1
All baseline failures are the selected 65535 witness; other selected baseline
responses equal their literal expectations. All corrected rows match.
No callable exceptions occurred; all recorded child stderr files are empty.
Accept-all fails -1, 0, 65536; reject-all fails 1, 2, 443, 65534, 65535.
These are two selected sensitivity controls, not a mutation campaign.
Counts: 3 classes, 8 unique integers, 6 gates, 41 repeated helper calls.
Child exit 0: every case in that selection passed.
Wrapper exit 0: expected contrasting passes AND failures reproduced.

EVIDENCE LOCATIONS
Public base: /assets/equivalence-partitioning/research-rerun/
Summary: observed/reproduction-summary.json
Per-gate records: observed/<gate-name>.stdout.json and .stderr.txt
Basis: contract.json, cases.json, validator.py, run_cases.py, reproduce.py
Complete identities: PROVENANCE.json, manifest.json, SHA256SUMS
Origin and instructions: origin.json, README.md
Kit: /assets/equivalence-partitioning/equivalence-partitioning-evidence-kit.zip

DISPOSITION, FRESHNESS AND NEXT ACTION
Supported: recorded selected responses and implemented endpoint correction.
Remaining: evidence that the required relation holds for unselected members.
No exhaustive enumeration, formal proof or defect-class closure is established.
No parser/type/overflow/collection/network or production acceptance claim.
No Proof CLI, solver or generated-property campaign was executed.
Stale-evidence triggers: changed rule, inclusivity, incoming representation,
upstream assumption, interaction/state, implementation/adapter, oracle,
harness, runtime/configuration or any recorded content identity.
After a change: assess impact and rerun affected selections, or record a
reasoned reuse decision with its reviewer and scope.
Proposed adopting responsibilities, not completed assignments:
  Rule owner: approve the actual domain and policy before project use.
  Implementation owner: bind the real caller and candidate, run its cases,
    and choose further within-class evidence before making a broader claim.
  Reviewer/acceptance authority: assess current results and remaining work.
Proposed accountable owner: engineer adopting this record.
Next action: enter named people or accountable queues for these roles,
and bind the actual caller and candidate revision.
Due event: before accepting this record as a project test plan.
Assignment/completion: not performed in this fictional exercise.

04 / The working method

How to build and challenge the partition table

1. Fix the boundary and authority. Name the approved rule, its revision, actual entrypoint, representations and relevant state. Resolve undefined outcomes with the policy owner before encoding them as passing expectations.
2. Inventory the incoming domain. Separate accepted values from rejected values that still reach the interface. For an exclusion, identify the upstream guarantee and its evidence or retain an open interface check.
3. Choose one characteristic and observation. Write the relation class members must share, including required payload or effects. Hold other relevant conditions fixed or model their combinations explicitly.
4. Write predicates and concrete witnesses. Review nonemptiness, overlaps and gaps over the declared domain. If you cannot produce a member, resolve feasibility before counting the class.
5. Choose representatives for a reason. Select an admissible member of every valid and invalid class. Add ordered endpoint witnesses and consequential combinations; preserve deduplicated inputs and selection purposes separately.
6. Execute against an independent expectation. Bind source, harness, literal expected observations, runtime and commands. Check that deliberate wrong behavior fails, then retain actual observations and missing work.
7. Revise the selection and evidence claim. Preserve a failing witness, correct the implementation when the rule is settled, and replay affected cases. Split a class only when the specified behavior or a useful selection characteristic warrants it. Assign the remaining within-class uncertainty and freshness review.

05 / Check the record before relying on it

Partition review checklist

• The rule, authority, interface and candidate are identifiable.
• Incoming and valid domains are distinct; rejected requests remain reachable.
• Every class has a predicate, concrete member and relevant shared-behavior rule.
• Nonemptiness, overlaps and domain coverage are reviewed under explicit assumptions.
• Representatives have rationales; ordered neighbors and interactions have a stated scope.
• Required observations are literal or independently derived, with relevant types and effects.
• Recorded results identify actual code, harness, commands and raw observations.
• Class counts, unique inputs and repeated calls use separate units.
• Controls, missing work, freshness triggers and the next accountable action are visible.

06 / Repair selection mistakes

Mistakes that make a partition table misleading

07 / Check the model and the implementation separately

Where Proof fits, and what its result means

Proof supports completeness and pairwise exclusivity checks for eligible authored input data_constraint groups under their parameter assumptions. That can help find modeled gaps and overlaps. It does not call this Python helper, separately establish every class's nonemptiness, or prove that implementation members behave equivalently. The source basis identifies the inspected grouping and result-handling code.

A parameter bound of 1..65535 removes both rejection classes from that model. It cannot establish rejection of zero or 65536. Review assumptions for consistency and require a concrete member for each proposed class before interpreting a model result.

For an installed Proof CLI and a configured project that actually contains specs/system, component port_validation, authored supported predicates and the required solver, these are optional command illustrations. They were not executed for this guide.

Copy proof verify-properties specs/system port_validation --format json --no-download
proof audit --check data_constraints_complete --verbose

Inspect the actual grouped work, skipped variables and disproved, unparsed, inconclusive or unavailable-solver results. A no-work pass or CLI exit 0 does not establish that every intended check was proved. Audit failure depends on the effective project and flag policy; repository merge requirements and release enforcement are separate configuration and authority.

For one supported written predicate, use Spec Lab to review its interpretation and planned cases. The hosted tool does not execute your repository or this fixture. Execute application checks in your own environment, retain their results, assess freshness, and record any acceptance decision separately.

08 / Choose the evidence your uncertainty needs

Which partitioning workflow should you use?

Python's unittest documentation distinguishes equality assertions from exact-type checks. The fixture uses its own recursive comparator, not unittest.

Hypothesis's integers, sampled_from and strategy documentation supports choosing generated values. Bounding generation to 1 through 65535 excludes both rejection classes. Use class-specific generation where useful and keep the explicit regression witnesses. No Hypothesis campaign ran here; a generator supplies neither requirement authority nor an exhaustive guarantee.

10 / Two other selection decisions

Two examples beyond an ordered integer range

Both examples below are illustrative, proposed test designs. Neither was executed.

An unordered mode needs behavioral classes

Suppose an interface receives exact strings, with case-sensitive modes preview and apply. The written rule requires preview to report a proposed change without storing it, apply to store that change, and every other string to reject without changing stored state.

Both recognized modes may be accepted, but their required effects differ. Alphabetical neighbors add no meaningful boundary obligation to this categorical rule. Observe stored state as well as the response. The incoming type assumption belongs in the record; this illustration supplies no parser or type-rejection evidence.

Covering each field can miss the forbidden combination

Suppose an authorization interface receives exact strings for role and action. Recognized roles are viewer and editor; recognized actions are read and write. The illustrative rule lets viewers read and editors read or write. Unknown roles or actions must reject. Assume all proposed combinations can reach the decision.

This selection exercises each recognized and unknown class in each field but omits (viewer, write), which must reject. Add that forbidden combination and (editor, read), which must allow. Retain a both-unknown case and resolve any required error reason or precedence before asserting it.

This is the gap in Each Choice coverage: exercising every class in each dimension does not exercise their combinations. ISTQB, §4.2.1 An unresolved combined-error outcome needs a policy owner, not an expected value copied from current code.

12 / Continue with the evidence you need

Related guides

• Data constraints completeness: investigate modeled gaps and overlaps under declared assumptions.
• Negative testing: exercise rejected requests and their required outcomes deliberately.
• Property-based testing: explore more values while retaining a meaningful property and domain.
• Differential testing: define what two computation paths must agree on and how to resolve a mismatch.
• Requirements-based testing: establish the approved expectation when the oracle is unresolved.
• Why tests pass while bugs ship: diagnose what an existing green result actually supports.