Test

---
name: test
description: Run all TMDb unit tests (Swift Testing, the TMDb test plan). Use after code changes and before a PR to verify unit tests pass — delegates the run to the tooling-runner agent (Haiku) and returns total/passed/failed counts plus each failure as Suite/test with file:line. For the live-API suite, use /integration-test.
---

# Run tests

Spawn the **`tooling-runner`** agent (Agent tool,
`subagent_type: tooling-runner` — its Haiku pin, command recipes, and
reporting contract live in `.claude/agents/tooling-runner.md`) with the
one-line task:

> Run the `test` target: the TMDb unit test suite.
> Package directory: `<your current working directory, absolute>`

**Always include that directory line.** The subagent does not reliably inherit
your working directory, and without it a run inside a git worktree silently
tests the main checkout instead — which reports *"no matching test cases
found"* for suites that exist, or passes without ever seeing your changes (see
`.claude/agents/tooling-runner.md`). Use your actual CWD — run `pwd` if you are
not certain of it.

Relay its report. Do **not** run the tests yourself — unless the report is
missing or malformed (below), which is the only sanctioned fallback.

If the report is unclear on a failure, read the log path it reports
(`.build/last-test.log`) rather than re-running. After fixing the issues,
re-invoke this skill to re-check. To re-check just the previously failing
tests faster, ask the runner for a scoped run instead:

> Run the `test` target scoped to `SuiteName/testName`.
> Package directory: `<your current working directory, absolute>`

## A count is not evidence that *your* new test ran

The full-suite log is an **aggregate** — it names failures only, never the tests
that passed. So `passed_tests: 3105` looks the same whether a test you just
wrote ran, or never compiled into the bundle. The runner is instructed not to
claim otherwise and to report `Names observed: no` for a full run; treat any
per-test claim about a *passing* test in a full-suite report as unfounded, and a
rising total as no evidence about any individual test.

When it matters that a **specific** new test executed — a reproducer for the bug
you are fixing, or a test guarding a branch that had none — ask for the scoped
run above and read the test names in its output. That output *does* name each
test. It costs seconds against an already-built bundle, and it is the difference
between "the suite is green" and "the thing I wrote is doing its job".

## If the report is missing or malformed

Judge the runner's report by **shape**, not by tone — the three outcomes are
distinguishable and must be handled differently:

| Report | What it means | What you do |
| --- | --- | --- |
| `Status: refused — …` | A **caller bug** (wrong/missing package directory) | **Surface it as a hard error and fix the call.** Never fall back — the runner is telling you your invocation was unsafe. |
| `Status: passed`/`failed` | A real result | Relay it; act on any failures |
| No report, empty, or missing the `Directory:`/`Status:` lines | The subagent **died** — the run is **void, not failed** | Re-invoke **once**. If it voids again, run `make -C "<the same absolute directory you passed the runner>" test` directly via Bash |

A fallback run is **disclosed in your summary** — say that you fell back and
why. It is never silently treated as an ordinary result.