pattern-test

Start with the shared testing guidance in:

• docs/common/ai/pattern-testing-guide.md

Read that guide first. It is the canonical reference.

Run tests with:

deno task cf test <pattern>.test.tsx

Imports resolve from the nearest ancestor whose deno.json(c) declares a
package name (packages/patterns for repo patterns). A failure naming an import
that "escapes the program root" means the test imports from above that root —
pass --root naming a common ancestor of every imported file.

Keep the complete list of test entry paths for deployment. A deployed source
revision carries those tests only when each entry is supplied with a repeatable
--test flag:

deno task cf piece new <pattern>.tsx --test <pattern>.test.tsx ...
deno task cf piece setsrc <pattern>.tsx --test <pattern>.test.tsx --cell <piece-id> ...

Repeat --test for multiple entry files and repeat the complete flag set on
every setsrc. The deployment command packages and type-checks attached tests
but does not execute them, so a successful cf test run remains required.

When working in a Pattern Factory Build workspace, also follow
docs/common/ai/pattern-factory-build-guide.md (as mandated by pattern-dev). It
defines Pattern Factory's build completion gate and expected coverage shape.

For patterns that stamp timestamps or IDs, prefer deterministic assertions over
recomputing time/random values inside the test itself.

If cf test fails before or during assertions, treat that as pattern debugging,
not as a reason to guess at a new test shape. Before the next repair, read:

• docs/development/debugging/README.md

Then follow the linked gotcha or workflow for the exact error. For Cell,
Writable, or reactive-value failures, re-consult reactivity.md and
new-cells.md (as mandated by pattern-dev).

Runtime notes:

• Use the cf skill, or read skills/cf/SKILL.md, when you need CLI command
  details.
• The detailed workflow reference remains
  docs/common/workflows/pattern-testing.md.

Done When

• deno task cf test exits 0 for every test file. A failing test is not a valid
  done state unless a concrete external, tooling, or environment blocker
  prevents further repair.
• New or changed source code has automated test coverage. PRs that introduce new
  untested lines of code will fail in CI.
• Coverage matches the testing guide's expected shape: the product contract, not
  only the happy path (first-run/default states; primary add, remove, edit,
  toggle, or submit flows; repeated actions; validation and edge-case branches
  from the spec).
• The pattern still compiles after any interface changes made to support
  testing.
• Every authored test entry is handed to deployment for attachment to the source
  revision.