Checkpoint: Regression Suite

Prepare a compact test plan for the catalogue library. Each public claim needs evidence from the right tool: invalid states and callback types from the compiler; validation, projection, duplicate ids and stale ordering from runtime cases.

Do not merely list tests. Implement a narrow helper and show a behavioral regression is detectable despite a clean type check. This checkpoint uses a count validator to keep the code small; the download applies the same method to the catalogue.

Use an assertion that throws on mismatch and print success only after every case. Keep malformed values typed unknown at the boundary. Include zero so your tests reject a truthiness-based implementation that accidentally excludes it.

Predict, run, and explain

Write the output and trace the important state changes before checking it. Then run the program. Use Check types first; execution is allowed only when the real compiler accepts the source.

Predict, then runTypeScript

const cases: readonly [unknown, boolean][] = [
  [0, true],
  [-1, false],
  ["0", false]
];

console.log(cases.length);

Enable JavaScript to edit and type-check this example.

Console output

Check your prediction

Acceptance cases before you code

Write a small test plan before implementing boundary regression family. These cases extend the brief; they are not a second worked solution. Predict the expected behavior independently, then test through the public function. A good ordinary example and a good boundary example should catch different possible mistakes.

Case to try	What your result should demonstrate
Zero and positive integer	Accept both
Negative, fraction, text and null	Reject with each fixture targeting one rule
Deliberate predicate weakening	At least one named fixture distinguishes the change

After the core task passes, deliberately break one rule and identify the case that notices it. Restore the implementation and explain the failure in terms of the contract, not the number of assertions. If a case requires a concept you have not recalled, revisit the relevant lesson before opening the solution.

Your turn

Exercise

Checkpoint: Regression Suite: practise

Implement isCount(value:unknown):boolean for finite nonnegative integers. Test zero, a positive integer, a negative integer, a decimal, numeric text and null using readonly [unknown,boolean] tuples. Print 6 cases passed.

Your workspaceTypeScript

// Use explicit expected outcomes, not expected values calculated by the same validator.

Enable JavaScript to edit and type-check this example.

Console output

Hint 1: the idea

The tuple keeps each input paired with its expected boolean.

Hint 2: a first step

Loop over [input, expected] and throw if the result differs.

Show one solution

One possible solutionTypeScript

function isCount(value: unknown): boolean {
  return (
    typeof value === "number" &&
    Number.isFinite(value) &&
    Number.isInteger(value) &&
    value >= 0
  );
}

const cases: readonly (readonly [unknown, boolean])[] = [
  [0, true],
  [2, true],
  [-1, false],
  [1.5, false],
  ["0", false],
  [null, false]
];

for (const [value, expected] of cases) {
  if (isCount(value) !== expected) {
    throw new Error("Count contract failed");
  }
}

console.log("6 cases passed");

Enable JavaScript to edit and type-check this example.

Console output

6 cases passed

Explain why the implementation meets the stated contract. Which part is enforced by the language or checker, and which part needs behavioral evidence?

Change it and test it

Mutate the integer check and the zero boundary separately; each should be caught. Then write two negative compile tests for an invalid state and a wrong callback return. State why those tests and the runtime cases cover different defects.

Predict, run, and explain

Acceptance cases before you code

Your turn

Change it and test it

Was this article helpful?