dxkit-test

dxkit-test

This skill closes the gap dxkit-action doesn't: it writes the missing tests rather than fixing flagged findings. It is the testing mirror of dxkit-docs — same shape, different dimension. It's built around one hard constraint: a test that doesn't actually exercise behavior (an empty expect(true), a snapshot of nothing, a call with no assertion) raises the coverage number while proving nothing. The whole point of this skill is tests that are grounded in real behavior and catch real regressions — not coverage theater.

The testing loop

[1] Read the gap   → test-gaps: the blast-radius-weighted untested worklist
[2] Orient         → graph: what the file does, who depends on it, what to assert
[3] Generate       → write real tests in the repo's framework + patterns
[4] Verify         → run the suite + coverage; Tests up, nothing red
[5] Guardrail      → guardrail check before pushing

Don't skip [2] or [4]. [2] is what makes the tests meaningful; [4] is what proves they pass and the coverage actually moved.

[1] Read the gap — what's actually untested, worst-first

Run the test-gaps report with graph context so the worklist is ranked by blast radius (how many files depend on each untested file), not just size:

npx vyuh-dxkit test-gaps --detailed --graph-context
npx vyuh-dxkit test-gaps --detailed --graph-context --json | jq '.actions, .gaps[0:10]'

The report partitions untested files into CRITICAL / HIGH / MEDIUM / LOW risk tiers, and within each tier the most-depended-on files surface first (the Graph context column shows role · N caller files). Work top-down: a 30-caller untested file is a bigger liability than a 500-line leaf nothing calls. The actions array names the top-K per tier with projected score uplift — that's your queue.

A blast radius n/a cell means graphify couldn't resolve that language's call graph (C# is the known case) — treat it as unknown, not "no callers," and fall back to the file's role + size to judge its risk.