Claims You Can Rerun

A test is a claim about behavior that a machine can check again tomorrow. Unit tests pin small pieces; contract tests check the promise between parts; regression tests keep a fixed mistake from returning. This site runs its own: when a check fails it names the rule it protects, which makes the test suite one of the better places to learn the codebase. Analysis deserves the same habit: a result you cannot rerun is a result you cannot defend.

Try to break a quiet-show rule with four concrete cases, then keep the results as a small test record.

#>testing_essentials

Testing Essentials

Tests with no framework

Node's built-in runner: describe, it, assert, and nothing to install.

node: test runner

How many of which kind

A practical account of balancing fast small tests with slower broad ones.

fowler: test pyramid

The wider field

Levels, methods, and vocabulary of software testing.

wiki: software testing

Try to break the quiet-show rule

Bring the cue-checking function and write expected results before running it. A useful test can disagree with the implementation.

Cases for “available and known to be silent”
Cue	Available	Sound	May play
Lantern	true	false	true
Bell	true	true	false
Missing ribbon	false	false	false
Unlabelled prop	true	unknown	false

On paper, evaluate each row. In JavaScript, paste these after the function; a failed assertion reports a disagreement in the console.

console.assert(canPlay({ available: true, sound: false }) === true,
  "A ready, silent lantern should pass");
console.assert(canPlay({ available: true, sound: true }) === false,
  "A ready bell should fail");
console.assert(canPlay({ available: false, sound: false }) === false,
  "A missing ribbon should fail");
console.assert(canPlay({ available: true }) === false,
  "Unknown sound status should fail");

Break it deliberately: change && to || in the function. The bell and missing ribbon tests should fail. Restore the rule and keep those cases so the same mistake is easier to catch later.

What these checks do not establish

They do not check whether every name in the running order has a cue record, whether a performer has the prop in hand, or whether the audience can follow the scene. Those need a lookup check, a rehearsal, and an observation. Passing four examples is evidence about those examples, not proof of every possible behavior.

Keep: input, expected result, observed result, and the version of the rule you used. Rehearse the approved order, then file the results with enough context to repeat them.