Design by Contract — Practice Tasks¶

11 hands-on exercises on making contracts explicit, enforceable, and testable. Each task gives you a scenario, code with an implicit or violated contract, an instruction, and a full solution with reasoning. Languages vary (Java / Python / Go). Ordered easy → hard.

Table of Contents¶

1. Task 1 — Surface the hidden precondition (Python, Easy)
2. Task 2 — Add a postcondition assertion (Go, Easy)
3. Task 3 — Define and maintain a class invariant (Java, Medium)
4. Task 4 — Remove the double-check (Python, Medium)
5. Task 5 — Promote a comment-contract to an enforced one (Java, Medium)
6. Task 6 — Loosen an over-strict precondition (Go, Medium)
7. Task 7 — Fix the LSP / contract break in a subtype (Java, Hard)
8. Task 8 — assert vs validate at a boundary (Python, Hard)
9. Task 9 — Turn a postcondition into a property-based test (Python, Hard)
10. Task 10 — Push a runtime contract into the type system (Go, Hard)
11. Task 11 — Contract audit (Java, open-ended)
12. Self-Assessment
13. Related Topics

How to Use¶

Each task is a small unit of deliberate practice. Work it like this:

1. Read the scenario and the code. Before looking at the instruction, ask yourself: what does this routine silently assume, and what does it silently promise? Those two questions are the entire discipline of Design by Contract.
2. Attempt the change in a scratch file before expanding the solution. Run it if the language is at hand — every solution here is runnable.
3. Open the solution and compare not just the code but the reasoning: who owns each obligation (caller or callee), and what would break if the contract were stated differently.
4. Re-check the blame assignment. A failed precondition blames the caller; a failed postcondition or invariant blames the callee. If your fix points the finger in the wrong direction, it is the wrong fix.

The mental model for the whole chapter:

Precondition broken → caller's bug. Postcondition or invariant broken → routine's bug. The contract is the line that decides who is at fault.

Task 1 — Surface the hidden precondition (Python, Easy)¶

Difficulty: Easy

Scenario: This helper computes a moving average. It works in every test and demo, yet it carries an assumption the signature never reveals.

def moving_average(values: list[float], window: int) -> list[float]:
    result = []
    for i in range(len(values) - window + 1):
        chunk = values[i:i + window]
        result.append(sum(chunk) / window)
    return result

Instruction: Identify the implicit preconditions and make them explicit at the top of the function. Choose an enforcement mechanism appropriate to a programmer-facing API (these are bugs in calling code, not untrusted external input). Document the contract.

def moving_average(values: list[float], window: int) -> list[float]:
    """Return the simple moving average of `values` over `window` samples.

    Preconditions (caller's responsibility):
        - window >= 1
        - 1 <= window <= len(values)
    Postcondition (this function's guarantee):
        - len(result) == len(values) - window + 1
    """
    if window < 1:
        raise ValueError(f"window must be >= 1, got {window}")
    if window > len(values):
        raise ValueError(
            f"window ({window}) exceeds number of values ({len(values)})"
        )

    result = [
        sum(values[i:i + window]) / window
        for i in range(len(values) - window + 1)
    ]
    assert len(result) == len(values) - window + 1  # postcondition
    return result

Task 2 — Add a postcondition assertion (Go, Easy)¶

Difficulty: Easy

Scenario: A function splits a slice into n near-equal contiguous chunks for parallel workers. The author believes it preserves every element, but nothing checks it.

func chunk[T any](items []T, n int) [][]T {
    size := len(items) / n
    rem := len(items) % n
    out := make([][]T, 0, n)
    start := 0
    for i := 0; i < n; i++ {
        end := start + size
        if i < rem {
            end++ // distribute the remainder
        }
        out = append(out, items[start:end])
        start = end
    }
    return out
}

Instruction: State the precondition explicitly and add a postcondition assertion that the partition is complete and disjoint (every input element appears exactly once across the chunks). Use a panic for the contract breach — a violation here is a logic bug, not recoverable input.

func chunk[T any](items []T, n int) [][]T {
    if n < 1 {
        panic(fmt.Sprintf("chunk: n must be >= 1, got %d", n)) // precondition
    }

    size := len(items) / n
    rem := len(items) % n
    out := make([][]T, 0, n)
    start := 0
    for i := 0; i < n; i++ {
        end := start + size
        if i < rem {
            end++
        }
        out = append(out, items[start:end])
        start = end
    }

    // Postcondition: the chunks form a complete, disjoint, ordered partition.
    total := 0
    for _, c := range out {
        total += len(c)
    }
    if total != len(items) || start != len(items) || len(out) != n {
        panic(fmt.Sprintf(
            "chunk postcondition violated: covered=%d start=%d want=%d chunks=%d want=%d",
            total, start, len(items), len(out), n))
    }
    return out
}

Task 3 — Define and maintain a class invariant (Java, Medium)¶

Difficulty: Medium

Scenario: A TemperatureRange is supposed to always satisfy min <= max. The class never says so, and one method quietly breaks it.

class TemperatureRange {
    private double min;
    private double max;

    public TemperatureRange(double min, double max) {
        this.min = min;
        this.max = max;
    }

    public void setMin(double min) { this.min = min; }
    public void setMax(double max) { this.max = max; }

    public boolean contains(double t) { return t >= min && t <= max; }
    public double span() { return max - min; }
}

Instruction: Make min <= max an enforced class invariant. The invariant must hold after construction and after every mutating method. Add a single private check that each mutator calls, and prove the invariant cannot drift.

class TemperatureRange {
    private double min;
    private double max;

    public TemperatureRange(double min, double max) {
        this.min = min;
        this.max = max;
        checkInvariant();
    }

    public void setMin(double min) {
        double old = this.min;
        this.min = min;
        try {
            checkInvariant();
        } catch (IllegalStateException e) {
            this.min = old;          // roll back so the object stays valid
            throw e;
        }
    }

    public void setMax(double max) {
        double old = this.max;
        this.max = max;
        try {
            checkInvariant();
        } catch (IllegalStateException e) {
            this.max = old;
            throw e;
        }
    }

    public boolean contains(double t) { return t >= min && t <= max; }
    public double span() { return max - min; } // safe: invariant guarantees >= 0

    /** Class invariant: min <= max. Holds after construction and every mutation. */
    private void checkInvariant() {
        assert max >= min : "invariant violated: min=" + min + " max=" + max;
        if (max < min) {
            throw new IllegalStateException(
                "TemperatureRange invariant violated: min=" + min + " max=" + max);
        }
    }
}

Task 4 — Remove the double-check (Python, Medium)¶

Difficulty: Medium

Scenario: A service validates that an order is payable, then calls a charge routine that validates the exact same thing again. The precondition is checked twice, on both sides of one call.

def process_checkout(order: Order) -> Receipt:
    if order is None:
        raise ValueError("order is required")
    if order.total <= 0:
        raise ValueError("order total must be positive")
    if order.status != "CONFIRMED":
        raise ValueError("order must be confirmed")

    return charge(order)


def charge(order: Order) -> Receipt:
    # defensive re-validation of the caller's guarantees
    if order is None:
        raise ValueError("order is required")
    if order.total <= 0:
        raise ValueError("order total must be positive")
    if order.status != "CONFIRMED":
        raise ValueError("order must be confirmed")

    receipt = gateway.charge(order.total, order.payment_method)
    return receipt

Instruction: Both functions live in the same module and charge is not a public entry point — process_checkout is the only caller. Decide where the precondition belongs, remove the duplication, and document the contract so the deletion is safe.

def process_checkout(order: Order) -> Receipt:
    """Public entry point: validates the order, then charges it."""
    _require_payable(order)          # the single source of truth
    return charge(order)


def _require_payable(order: Order) -> None:
    if order is None:
        raise ValueError("order is required")
    if order.total <= 0:
        raise ValueError("order total must be positive")
    if order.status != "CONFIRMED":
        raise ValueError("order must be confirmed")


def charge(order: Order) -> Receipt:
    """Charge a payable order.

    Precondition (caller's responsibility): `order` is non-None, CONFIRMED,
    and has a positive total. The only caller, `process_checkout`, guarantees
    this via `_require_payable`. This routine does NOT re-validate.
    """
    assert order is not None and order.status == "CONFIRMED" and order.total > 0
    return gateway.charge(order.total, order.payment_method)

Task 5 — Promote a comment-contract to an enforced one (Java, Medium)¶

Difficulty: Medium

Scenario: This method's contract lives entirely in a Javadoc comment. Nothing enforces it, and nothing tests it.

/**
 * Computes compound interest.
 *
 * @param principal the starting amount, must be > 0
 * @param annualRate the rate as a decimal, must be >= 0 (e.g. 0.05 for 5%)
 * @param years the term in years, must be > 0
 * @return the final balance, always >= principal
 */
public double compound(double principal, double annualRate, int years) {
    return principal * Math.pow(1 + annualRate, years);
}

Instruction: Turn each @param ... must be clause into an enforced precondition and the @return ... always clause into an enforced postcondition. Then sketch the test that proves the contract is real.

import static java.util.Objects.requireNonNull;

/**
 * Computes compound interest.
 *
 * @param principal the starting amount, must be > 0
 * @param annualRate the rate as a decimal, must be >= 0 (e.g. 0.05 for 5%)
 * @param years      the term in years, must be > 0
 * @return the final balance, guaranteed >= principal
 * @throws IllegalArgumentException if any precondition is violated
 */
public double compound(double principal, double annualRate, int years) {
    // Preconditions — caller's obligations, enforced.
    if (principal <= 0) throw new IllegalArgumentException("principal must be > 0, got " + principal);
    if (annualRate < 0) throw new IllegalArgumentException("annualRate must be >= 0, got " + annualRate);
    if (years <= 0)     throw new IllegalArgumentException("years must be > 0, got " + years);

    double balance = principal * Math.pow(1 + annualRate, years);

    // Postcondition — this method's guarantee.
    assert balance >= principal
        : "postcondition violated: balance " + balance + " < principal " + principal;
    return balance;
}

@Test void rejectsNonPositivePrincipal() {
    assertThrows(IllegalArgumentException.class, () -> compound(0, 0.05, 10));
    assertThrows(IllegalArgumentException.class, () -> compound(-1, 0.05, 10));
}

@Test void rejectsNegativeRate() {
    assertThrows(IllegalArgumentException.class, () -> compound(100, -0.01, 10));
}

@Test void rejectsNonPositiveYears() {
    assertThrows(IllegalArgumentException.class, () -> compound(100, 0.05, 0));
}

@Test void balanceNeverDropsBelowPrincipal() {
    // With rate >= 0 and years > 0, the postcondition must always hold.
    assertTrue(compound(100, 0.0, 5) >= 100);   // zero rate: balance == principal
    assertTrue(compound(100, 0.05, 5) >= 100);  // positive rate: balance grows
}

Task 6 — Loosen an over-strict precondition (Go, Medium)¶

Difficulty: Medium

Scenario: A normalization helper rejects inputs it could perfectly well handle. The precondition is stricter than the routine actually requires, pushing needless ceremony onto every caller.

// Normalize scales a vector to unit length.
// Precondition: v must have exactly 3 elements (x, y, z).
func Normalize(v []float64) ([]float64, error) {
    if len(v) != 3 {
        return nil, fmt.Errorf("vector must have exactly 3 elements, got %d", len(v))
    }
    var sumSq float64
    for _, x := range v {
        sumSq += x * x
    }
    mag := math.Sqrt(sumSq)
    out := make([]float64, len(v))
    for i, x := range v {
        out[i] = x / mag
    }
    return out, nil
}

Instruction: The len(v) == 3 rule is a fiction — the algorithm works for any dimension. But there is a genuine precondition the code currently ignores. Replace the over-strict rule with the precondition the routine actually needs, and explain the difference.

// Normalize scales a non-zero vector to unit length.
// Precondition: v is non-empty and not the zero vector (magnitude > 0).
// Postcondition: the returned vector has the same dimension as v and
// (within floating-point tolerance) unit length.
func Normalize(v []float64) ([]float64, error) {
    if len(v) == 0 {
        return nil, fmt.Errorf("vector must be non-empty")
    }
    var sumSq float64
    for _, x := range v {
        sumSq += x * x
    }
    if sumSq == 0 {
        return nil, fmt.Errorf("cannot normalize the zero vector")
    }
    mag := math.Sqrt(sumSq)
    out := make([]float64, len(v))
    for i, x := range v {
        out[i] = x / mag
    }
    return out, nil
}

Task 7 — Fix the LSP / contract break in a subtype (Java, Hard)¶

Difficulty: Hard

Scenario: FileStore.save accepts any non-null byte array. A subclass EncryptedFileStore overrides it but strengthens the precondition — it now also requires the payload to be a multiple of the cipher block size. Code written against FileStore breaks when handed an EncryptedFileStore.

class FileStore {
    /** Precondition: data != null. Saves the bytes; returns the storage key. */
    public String save(byte[] data) {
        Objects.requireNonNull(data, "data");
        return write(data);
    }
}

class EncryptedFileStore extends FileStore {
    @Override
    public String save(byte[] data) {
        Objects.requireNonNull(data, "data");
        // STRENGTHENED precondition — not in the parent's contract:
        if (data.length % 16 != 0) {
            throw new IllegalArgumentException("data length must be a multiple of 16");
        }
        return write(encrypt(data));
    }
}

Instruction: Identify the Liskov violation precisely (precondition strengthened) and fix it so EncryptedFileStore is a true behavioural subtype — usable anywhere a FileStore is expected. State the LSP rule for contracts.

class EncryptedFileStore extends FileStore {
    private static final int BLOCK = 16;

    @Override
    public String save(byte[] data) {
        Objects.requireNonNull(data, "data"); // same precondition as parent — not stronger
        byte[] padded = pkcs7Pad(data, BLOCK); // subtype's job, not the caller's
        return write(encrypt(padded));
    }

    /** PKCS#7 padding: bring length up to a multiple of `block`. */
    private static byte[] pkcs7Pad(byte[] data, int block) {
        int padLen = block - (data.length % block);
        if (padLen == 0) padLen = block; // PKCS#7 always adds at least one block-marker
        byte[] out = Arrays.copyOf(data, data.length + padLen);
        for (int i = data.length; i < out.length; i++) {
            out[i] = (byte) padLen;
        }
        return out;
    }
}

Task 8 — assert vs validate at a boundary (Python, Hard)¶

Difficulty: Hard

Scenario: A single function mixes two fundamentally different kinds of check. One guards against external, untrusted input; the other guards against internal programmer error. The code treats them identically, which makes the failure modes lie about who is at fault.

def apply_discount(request: dict, catalog: Catalog) -> Decimal:
    # 'request' arrives straight from an HTTP body (untrusted)
    code = request["coupon"]
    qty = request["quantity"]
    sku = request["sku"]

    product = catalog.find(sku)
    discount = DISCOUNTS[code]          # internal table, populated at startup
    price = product.price * qty
    final = price - (price * discount.rate)
    return final

Instruction: Two trust levels are tangled here. Separate them: external input must be validated (recoverable — return a 4xx-style error to the client), while internal invariants must be asserted (a contract breach is a bug — fail fast and loud). Classify every access and rewrite accordingly.

class BadRequest(Exception):
    """Recoverable: the client sent something invalid -> map to HTTP 400."""


def apply_discount(request: dict, catalog: Catalog) -> Decimal:
    # ---- boundary: VALIDATE untrusted input ----
    code = request.get("coupon")
    sku = request.get("sku")
    qty = request.get("quantity")

    if not isinstance(sku, str) or not sku:
        raise BadRequest("sku is required")
    if not isinstance(qty, int) or qty < 1:
        raise BadRequest("quantity must be a positive integer")
    if code not in DISCOUNTS:                 # validate against the known set
        raise BadRequest(f"unknown coupon: {code!r}")

    product = catalog.find(sku)
    if product is None:                       # sku is client-supplied -> validate
        raise BadRequest(f"unknown sku: {sku!r}")

    # ---- inside the boundary: ASSERT internal contracts ----
    discount = DISCOUNTS[code]
    # We already validated `code in DISCOUNTS`, so this lookup MUST succeed;
    # if a rate is out of range, our startup table is corrupt -> programmer bug.
    assert 0 <= discount.rate <= 1, f"corrupt discount rate for {code}: {discount.rate}"
    assert product.price >= 0, f"catalog returned negative price for {sku}"

    price = product.price * qty
    final = price - (price * discount.rate)

    # postcondition: a discount never increases the price, never goes negative
    assert 0 <= final <= price, f"discount postcondition violated: {final} not in [0, {price}]"
    return final

Task 9 — Turn a postcondition into a property-based test (Python, Hard)¶

Difficulty: Hard

Scenario: A roman codec has a round-trip postcondition stated only in a comment: decoding what we encoded yields the original number. Example-based tests check a handful of cases and miss the gaps.

def to_roman(n: int) -> str:
    # Precondition: 1 <= n <= 3999
    # Postcondition: from_roman(to_roman(n)) == n   (round-trip)
    numerals = [(1000,"M"),(900,"CM"),(500,"D"),(400,"CD"),(100,"C"),
                (90,"XC"),(50,"L"),(40,"XL"),(10,"X"),(9,"IX"),
                (5,"V"),(4,"IV"),(1,"I")]
    out = []
    for value, symbol in numerals:
        while n >= value:
            out.append(symbol)
            n -= value
    return "".join(out)

def from_roman(s: str) -> int: ...

Instruction: The round-trip postcondition is a universal property — it should hold for every valid n, not three examples. Convert it into a property-based test (use Hypothesis) that exercises the whole domain, and also encode the precondition as an enforced check. Explain why a property test is the natural home for a postcondition.

def to_roman(n: int) -> str:
    if not (1 <= n <= 3999):
        raise ValueError(f"to_roman requires 1 <= n <= 3999, got {n}")
    numerals = [(1000,"M"),(900,"CM"),(500,"D"),(400,"CD"),(100,"C"),
                (90,"XC"),(50,"L"),(40,"XL"),(10,"X"),(9,"IX"),
                (5,"V"),(4,"IV"),(1,"I")]
    out = []
    for value, symbol in numerals:
        while n >= value:
            out.append(symbol)
            n -= value
    return "".join(out)

from hypothesis import given, strategies as st

# Postcondition as a universal property: round-trip is the identity.
@given(st.integers(min_value=1, max_value=3999))
def test_roman_round_trips(n):
    assert from_roman(to_roman(n)) == n

# Precondition is enforced: out-of-range input is rejected, never silently mishandled.
@given(st.integers().filter(lambda x: x < 1 or x > 3999))
def test_to_roman_rejects_out_of_range(n):
    import pytest
    with pytest.raises(ValueError):
        to_roman(n)

# A second postcondition worth stating: output uses only valid symbols.
@given(st.integers(min_value=1, max_value=3999))
def test_output_contains_only_roman_symbols(n):
    assert set(to_roman(n)) <= set("MDCLXVI")

Task 10 — Push a runtime contract into the type system (Go, Hard)¶

Difficulty: Hard

Scenario: An email-sending routine re-validates its address on every call. The precondition ("to is a syntactically valid email") is checked at runtime, in every function that takes an address, scattered and repeated.

func SendWelcome(to string) error {
    if !isValidEmail(to) {
        return fmt.Errorf("invalid email: %q", to)
    }
    return smtp.Send(to, "Welcome!", body)
}

func SendReceipt(to string, r Receipt) error {
    if !isValidEmail(to) {                // same precondition, checked again
        return fmt.Errorf("invalid email: %q", to)
    }
    return smtp.Send(to, "Your receipt", render(r))
}

Instruction: A precondition that every function repeats is begging to become a type. Introduce a type that can only hold a valid email, so validation happens once at construction and the contract is then enforced by the compiler — SendWelcome/SendReceipt no longer need (or are able) to receive an invalid address. Show why this is strictly stronger than the runtime checks.

// Email is a string that has been validated at construction time.
// Its zero value is unusable; the only way to obtain a non-empty Email is
// through NewEmail, which enforces the precondition exactly once.
type Email struct {
    addr string
}

func NewEmail(raw string) (Email, error) {
    raw = strings.TrimSpace(raw)
    if !isValidEmail(raw) {
        return Email{}, fmt.Errorf("invalid email: %q", raw)
    }
    return Email{addr: raw}, nil
}

func (e Email) String() string { return e.addr }

// Consumers now state the contract in their *signature*. There is no runtime
// check because there is no way to construct an invalid Email to pass in.
func SendWelcome(to Email) error {
    return smtp.Send(to.String(), "Welcome!", body)
}

func SendReceipt(to Email, r Receipt) error {
    return smtp.Send(to.String(), "Your receipt", render(r))
}

to, err := NewEmail(request.FormValue("email")) // validate at the boundary
if err != nil {
    http.Error(w, err.Error(), http.StatusBadRequest)
    return
}
_ = SendWelcome(to) // and everywhere downstream the compiler guarantees validity

Task 11 — Contract audit (Java, open-ended)¶

Difficulty: Hard (open-ended)

Scenario: Below is a realistic BankAccount. It has implicit preconditions, an undeclared invariant, a comment-contract, a double-check, and a latent LSP trap waiting for a subclass. Audit it.

class BankAccount {
    private long balanceCents;       // can go negative today — should it?
    private final String owner;
    private boolean frozen;

    public BankAccount(String owner, long openingCents) {
        this.owner = owner;
        this.balanceCents = openingCents;
    }

    /** Deposit money. amount must be positive. */
    public void deposit(long cents) {
        if (cents <= 0) throw new IllegalArgumentException("amount must be positive");
        balanceCents += cents;
    }

    public void withdraw(long cents) {
        if (cents <= 0) throw new IllegalArgumentException("amount must be positive");
        balanceCents -= cents;       // no overdraft guard
    }

    public void transfer(BankAccount to, long cents) {
        if (cents <= 0) throw new IllegalArgumentException("amount must be positive");
        if (cents > balanceCents) throw new IllegalStateException("insufficient funds");
        this.withdraw(cents);        // withdraw re-checks cents > 0  (double-check)
        to.deposit(cents);
    }
}

Instruction: List every contract defect (implicit precondition, missing invariant, comment-only contract, double-check, missing postcondition, LSP risk), then write a one-line fix plan for each. You do not need to produce the full rewritten class, but state the invariant precisely.

Self-Assessment¶

Rate yourself honestly after working the tasks. You have internalized Design by Contract when you can answer "yes" to all of these:

• Given any function, I can state its precondition, postcondition, and (for a class) invariant without running it.
• When an assertion fails, I can say immediately who is to blame — caller (precondition) or callee (postcondition/invariant).
• I can decide correctly between assert (contract breach / programmer bug) and validate-and-recover (untrusted input) at any boundary, and I never confuse the two.
• I can spot a double-check and decide which side legitimately owns the precondition.
• I can recognize an LSP / contract violation in a subtype (strengthened precondition or weakened postcondition) and fix it without breaking substitutability.
• I can turn a postcondition into a property-based test when it is a universal property over the input domain.
• I can identify when a repeated runtime precondition should be promoted into the type system so its violation becomes unrepresentable.
• I can spot an over-strict precondition — one that rejects inputs the routine could handle — and weaken it to the minimum the postcondition actually needs.

If any box is unchecked, re-do the matching task and read the reasoning, not just the code.

Related Topics¶

• junior.md — the entry-level walkthrough of preconditions, postconditions, and invariants for this chapter.
• find-bug.md — buggy snippets where a broken or unstated contract is the root cause.
• optimize.md — tightening and relocating contracts (toward types and boundaries) for clarity and safety.
• Chapter README — the positive rules of Design by Contract.
• Defensive vs Offensive — the stance toward bad input; the complement to this chapter's formal contracts.
• Refactoring — many contract fixes (extract validation, introduce value object) are refactorings; this section catalogs the mechanics.

Next: find-bug.md — find the broken contracts hiding in code that looks correct.