tmu
74c39e1346
Same decisions, rationale, rejected alternatives and known issues, said with less padding: ~5,530 -> ~4,730 words (-15%). Every fact from the first draft is kept; only the wording, duplicated lead-ins and restated context are cut.
1.9 KiB
1.9 KiB
Testing
For this library the types are the feature, so a runtime-only test loop would verify the wrong thing. The commands are in CONTRIBUTING.md; this file records why the loop is shaped the way it is.
Type-driven development
The rules — the loop and the pairing rule — are in CONTRIBUTING.md § Testing discipline (type-driven). What follows is why and what was rejected.
Decision (2026-09)
The compile-time expectation is written before the runtime assertion, and both before the implementation.
Why
- A runtime-only test can pass while the type is wrong, so a type-level library would ship a broken feature its tests bless.
- The type error is a more precise spec than a failing assertion, because it states the exact expected type before the logic exists.
Rejected
- Runtime-first (classic red/green): it verifies the value, not the contract, and the contract is the product.
- Testing the type only: it would not catch handler wiring,
exhaustive()throwing, or theotherwisefallback (seesrc/index.test.ts).
The runner is node --test --strip-types "src/**/*.test.ts" and the tiers are in
CONTRIBUTING.md § Development commands.
c8 uses V8 coverage, so the --strip-types source is instrumented without a
build step, and the runner relies on the .ts import-extension convention (see
tooling.md).
Known issues
- The type-aware linter misidentifies
expectTypeOf()as a floating promise, sosrc/index.test.tscarries a file-leveloxlint-disable typescript/no-floating-promiseswith an explanatory comment. It is a known false positive, not a rule worth disabling project-wide (see tooling.md § oxlint-disable directives live next to the code).