Writing tests

SkillDev tools

Guides your agent to write, review, and place tests so they catch real regressions instead of coupling to code shape.

Then ask your AI: use the Writing tests skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Add it as a step in a pipeline you build on Ahel, or connect Ahel to Claude, ChatGPT, Cursor, Claude Code or Codex and ask your AI to use it.

About this skill

Use when writing or reviewing tests, or deciding whether a change needs one.

What this skill tells your AI

The instructions your AI receives, as published by bholmesdev/hubble.md in .agents/skills/writing-tests/SKILL.md and read by Ahel’s review.

Shape coverage like Kent C. Dodds' testing trophy: static checks at the base, a thin layer of unit tests, most confidence from integration tests, and the smallest budget for end-to-end tests.

When a test is warranted

A test is warranted when it catches a plausible regression that nothing else would. Prove it before keeping the test:

  1. Revert the source change, keeping the test. Run it and confirm it goes red.
  2. Read the failure. It should fail on the behavior in the test's name, not on a changed signature, a missing helper, or a setup error.
  3. If the change touches several behaviors, revert each one separately and confirm a test goes red for each.

A test that stays green on revert, or goes red for the wrong reason, is coupled to the code's shape instead of its behavior. Rewrite its assertion or delete it.

Good candidates: bug fixes, tricky UI behavior (focus handoff, keyboard flows, races between async work and navigation), and edge cases in pure logic (Markdown parsing and serialization, paths, rename rules). Glue code, prop pass-through, and variations of an already-covered behavior get no test of their own.

Pick the layer

LayerHereUse for
StaticBiome, tsc, pnpm check:react-compilerAnything a type or lint rule can catch
UnitVitest on pure functionsParsers, serializers, path logic
Integration (default)Vitest + happy-dom, rendering real components against real storesUI behavior, store actions
End-to-endPlaywright driving ElectronA few core flows where a break loses users' work: opening, editing, and saving notes; creating and renaming files

happy-dom has no layout. Verify sticky, scroll, overflow, and positioning by hand with the test-desktop-app skill and put a screenshot in the PR, rather than asserting DOM structure. Most changes get no end-to-end test.

Mock at the seam

Fake only what crosses a process or time boundary: desktopApi/IPC, the filesystem, the network, timers, requestAnimationFrame. Keep stores, components, and the editor real. apps/desktop/src/store/actions.test.ts shows the pattern: a fake desktop API with the real store behind it.

If a test needs to mock internal modules to reach the behavior, move it one layer up so those modules run for real.

Signals

GitHub stars
1k
Forks
97
Last commit
Oct 2026
Advanced
Item type
skill
Key
writing-tests-bholmesdev
Source
github.com/bholmesdev/hubble.md