Properties catch what examples miss

The limit of examples

An example test says "this input gives that output". It is precise, it is easy to read, and it covers exactly one point in an infinite space. You can write twenty of them and still miss the case that matters, because you chose all twenty and you chose them from the same mental model that wrote the code.

A property is a claim that holds for every valid input. You do not have to guess which input breaks it. You write the claim once and let a loop go looking.

Four kinds cover most of what you will need.

Round trip

Encoding then decoding must give back what you started with.

for n in range(1, 200):
    original = "a" * n
    assert decode(encode(original)) == original

Invariant

Something must be true of the output no matter what went in. Splitting a bill preserves the total. Sorting preserves the multiset of elements. A discount never produces a negative price.

parts = split_evenly(total, count)
assert sum(parts) == total                  # nothing was created or lost
assert max(parts) - min(parts) <= 1         # the split is actually even

Idempotence

Applying it twice is the same as applying it once. True of normalizing, trimming, deduplicating, and most "clean this up" functions, and very often false in the implementation.

assert normalize(normalize(text)) == normalize(text)

Agreement with something obviously correct

A slow, dull, clearly-right implementation is a specification you can execute. The fast one must agree with it on every input.

Searching for the smallest violation

Once you have a property, finding a counterexample is a loop. Start small and stop at the first failure, because the smallest failing input is the easiest one to reason about.

def first_round_trip_failure(limit):
    for n in range(1, limit + 1):
        original = "a" * n
        try:
            if decode(encode(original)) != original:
                return n
        except Exception:
            return n            # a crash is a violation too
    return -1

The try matters. A property can be violated by a wrong answer or by an exception, and a search that only handles the first stops at the second. This is one of the few places where catching Exception broadly is right: inside a probe you genuinely do want every failure mode to count as a failure, and the exception is being converted into a verdict rather than discarded.

Where properties come from

You do not invent them. You read the contract and translate each promise into something executable.

If a promise in the contract has no executable form, that is worth noticing on its own: it usually means the requirement is not yet specific enough to build against, and asking the question is a more valuable review comment than any test.

Interview nuance: in a pairing interview, "what property should always hold here?" is a question you can ask about any function on the screen, and it moves the conversation from typing to specification instantly. For a sort it is "the output is a permutation of the input". For a cache it is "a hit returns exactly what was written". Interviewers notice, because most candidates only ever discuss examples.