Durable, language-agnostic testing principles, plus a router to the dialect of whatever language you are testing. A test earns its keep by failing when behavior breaks and staying green through refactors.

For general code quality while writing the code under test, use the

code-craft

skill; this one covers the tests.

Pick the feature boundary first, then test inputs to outputs across it. Good boundaries are the ones a user or a caller actually cares about: config parsing, request handling, a planning/translation step, a state transition. Tests that poke internal helpers directly tend to pin the current implementation and break on every refactor while catching few real bugs.

Prefer the public API. Exhaustive tests of a private helper, fed inputs no caller ever passes, are change detectors in disguise; if the helper deserves that much testing, it deserves to be a public unit.

A helper with a table of cases beats a dozen tests that each call private functions. Data in, data out, assert on the data.

A change-detector test is a transformation of the same information as the code under test. The absurd form reads the production source and asserts each line; that is obviously a checksum, not a test. The common form is only superficially different: mock every collaborator and verify the exact sequence of internal calls.

// Production code:
def process(w: Work)
  firstPart.process(w)
  secondPart.process(w)

// Test code:
part1 = mock(FirstPart)
part2 = mock(SecondPart)
w = Work()
Processor(part1, part2).process(w)
verify_in_order
  was_called part1.process(w)
  was_called part2.process(w)

This test restates the implementation. A correct and an incorrect program are equally likely to pass it, and any change to the production code breaks it without verifying the behavior of either version.

The symptom: a refactor with no behavior change turns the suite red, and fixing it means mechanically applying one transformation across many tests (add a parameter, update a hundred call sites with an empty string). When a test failure is fixed by mirroring the production edit rather than by thinking about behavior, the test is a change detector.

Change detectors have negative value: they catch no defects and their maintenance cost slows every future change. Rewrite them to assert state, a return value, rendered output, or persisted data, or delete them. Deletion is a valid fix; a test that cannot fail for a real reason protects nothing. Two questions expose one: could this test fail while observable behavior stays correct? Could behavior break while this test passes? A yes to either means rewrite or delete.

Push IO (filesystem, network, clock, randomness) to the edges so the core logic is a pure function you can test by building values in memory. A function that takes the parsed config and returns a plan is trivial to test; one that reads the file, calls the network, and writes the result is not. Separate them.

Give the shell honest seams: inject long-lived collaborators through the constructor and pass per-call data as method arguments. A hidden singleton, a static call, or a buried inside the logic under test is a dependency the test cannot control.

Mocks that record "method X was called with Y" test the implementation, not the behavior (see change detectors above), and they drift from reality. Work down this list and stop at the first entry that fits:

Two hard rules:

If you find yourself asserting on call counts and argument matchers, you are testing the wrong layer.

Name the bug you are defending against first, then take the topmost row of this table that can catch it. Escalate a row only when the cheaper layer would miss the risk, and say what it would miss.

When two layers could both catch the risk, compare them on SMURF: Speed, Maintainability, Utilization (resource cost), Reliability, Fidelity. Prefer the faster, cheaper, more reliable layer.

On coverage: meters find untested gaps; they do not certify quality. Cover both sides of every branch (an with no still has an implicit else worth a case). Do not enumerate input combinatorics; extract each predicate and cover it independently.

Keep unit tests in-source and close to the code, keep integration tests few and high-value behind one modular surface, and use doctests or runnable examples where the language supports them cheaply; they keep docs honest.

Tests have no tests, so a reader must be able to verify one by eye. That means DAMP (descriptive and meaningful phrases) beats DRY inside a test body: prefer a little repetition over indirection that hides cause and effect.

Flaky tests are worse than no tests because they train people to ignore red.

When the input space is large or has invariants (round-trip encode/decode, sort is a permutation, parse then serialize equals input), use property tests (proptest, fast-check, gopter, hypothesis) to generate cases and shrink failures. They find the edge you did not think to write.

A test proves nothing until you have seen it red for the right reason.

A test you would merge:

Detect the language, then read its file for the runner, fixture idioms, async test support, and property-test library.

languages/rust.md

*.rs

Cargo.toml

languages/typescript.md

*.ts

*.tsx

*.js

tsconfig.json

package.json

languages/go.md

*.go

go.mod

languages/python.md

*.py

pyproject.toml

requirements.txt

For a language not listed, apply the universal core directly and follow the project's existing test conventions; the principles transfer.

Project instructions and existing test conventions win over this skill. If a repo's / or its established patterns conflict with a principle here, follow the repo and say so. This skill is the default, not an override.

Distilled from Google's Testing on the Toilet series (2007-2026): the change-detector section is from Alex Eagle's "Change-Detector Tests Considered Harmful" (2015), and the double taxonomy, layer table, SMURF, DAMP rules, and prove-it-can-fail loop follow the episodes indexed in

references/episodes.md

, by way of

shamashel/testing-on-the-toilet

's distillation. The rest was carved out of the code-craft skill's testing principle.