Testing Input Contract Boundaries When Green Suites Lie

A test suite with 100% line coverage can fail on its second day in production. This is not a failure of diligence; it is a structural blind spot.

Developers write tests against the mental model they used to write the code. If an engineer assumes a range header always contains two positive integers separated by a hyphen, their unit tests will supply two positive integers separated by a hyphen.

def parse_content_range(header: str) -> tuple[int, int, int]:
    # Expects "bytes 0-499/1234"
    unit, rest = header.split(" ")
    range_part, total = rest.split("/")
    start, end = range_part.split("-")
    return int(start), int(end), int(total)

The test passes. CI turns green. But the suite did not verify the contract; it verified that the code executes when fed its own assumptions. When production traffic hands this function bytes 500-200/100, bytes -/100, or an empty string, it crashes with an unhandled ValueError or IndexError.

The green suite lied. It proved the code ran, not that it safely handled its input contract.

The Gap Between Types and Domain Boundaries

Type systems provide coarse boundaries. In Python, Rust, Go, or TypeScript, a string is any arbitrary sequence of characters or bytes. An integer is any value within the allocation width. But domain contracts are narrow: an account identifier is not just a string; it is an alphanumeric ASCII sequence between 8 and 32 characters, containing no control codes, with no leading whitespace.

The gap between what the type allows and what the business domain permits is unhandled edge space.

Type boundary:   [------------------ Any string ------------------]
Domain contract:           [-- 8-32 ASCII alphanumeric --]
Unhandled edge:  [--------]                               [--------]

When tests only sample points inside the domain contract, the code's behavior across the unhandled edge remains completely unasserted. Silent truncation, integer wrap-around, unhandled exceptions, and invalid internal states all hide inside green builds.

Relying on happy-path assertions confuses execution with verification. Passing a test proves only that the harness supplied an input the implementation survived.

Deterministic Boundaries Over Random Noise

The standard remedy is often fuzzing: throw millions of random byte sequences at the function until something breaks. Fuzzing has its place, but randomized fuzzing is expensive, non-deterministic, and often impractical to run on every commit.

Deterministic boundary analysis is more disciplined. For every input parameter, the contract has discrete topological boundaries:

• Magnitude edges: Minimum allowable value, minimum minus one, zero, maximum allowable value, maximum plus one.
• Structural edges: Empty payloads, single-element structures, structures at maximum capacity, nested nulls.
• Lexical edges: Valid UTF-8 containing non-printable control characters, multi-byte sequences, unescaped delimiters, leading/trailing whitespace.
• Relational edges: When parameter $A$ dictates the valid range of parameter $B$ (such as offset and length), test $B > A$, $A + B > \text{limit}$, and negative intervals.

A systematic test harness executes these specific boundary vectors as standard procedure. It does not guess. It directly targets the structural limits of the contract.

Explicit Rejection Is a Success State

A boundary test does not expect the function to process invalid data successfully. It asserts that the software fails cleanly, deterministically, and via a declared interface.

There is a fundamental difference between an unhandled runtime panic and a typed domain error:

## Unhandled failure: contract violated, behavior undefined
Traceback (most recent call last):
  File "parser.py", line 4, in parse_content_range
    start, end = range_part.split("-")
ValueError: not enough values to unpack (expected 2, got 1)

## Handled boundary: contract enforced, behavior deterministic
class InvalidRangeHeader(Exception):
    pass

def parse_content_range(header: str) -> tuple[int, int, int]:
    try:
        unit, rest = header.split(" ", 1)
        if unit != "bytes":
            raise InvalidRangeHeader(f"Unsupported unit: {unit!r}")
        range_part, total_str = rest.split("/", 1)
        start_str, end_str = range_part.split("-", 1)
        start, end, total = int(start_str), int(end_str), int(total_str)
        if start < 0 or end < start or end >= total:
            raise InvalidRangeHeader(f"Unsatisfiable range: {start}-{end}/{total}")
        return start, end, total
    except (ValueError, AttributeError) as exc:
        raise InvalidRangeHeader(f"Malformed header format: {header!r}") from exc

When an invalid input arrives, returning a structured rejection is not a failed test. It is proof that the boundary exists in code rather than in the caller's good intentions.

Writing resilient software does not mean writing more lines of test setup. It means enumerating the topological edges of every parameter, enforcing the domain contract at the boundary, and asserting that every out-of-bounds input terminates in a known, handled state before it touches internal logic.