chimera-test-the-wiring-not-the-class

You built a component that production reaches indirectly: through a factory, a registry, a plugin loader, a config flag, a router, a CLI entrypoint, a dependency-injection container. Your tests construct it directly and call its methods.

Every one of those tests can pass while the component is unreachable in the running system — because nothing in them exercises the registration, the default value of the flag, or the branch in the assembler that decides whether to include it at all.

It does not apply to a pure function that callers import and call directly. There, the import is the wiring, and a unit test covers it. It also does not apply when you are deliberately testing an algorithm in isolation — those tests are correct and should stay; this card says they are not sufficient on their own.

1. Name the entrypoint a user actually hits: the CLI subcommand, the HTTP route, the agent's run loop, the scheduled job. Write it down before writing the test.

2. Write at least one test that starts there and passes no constructor arguments for your component. If the test has to name your class to make the feature happen, it is not testing the wiring.

3. Build the object the way production builds it — call the real factory or config loader:

   # WRONG — proves the class, not the wiring: the component is handed to the thing under test,
   # so the test passes whether or not anything in production ever hands it over.
   assert "reminder" in render(feature=Feature(text="reminder"))
   
   # RIGHT — build it the way the entry point builds it, then look for the same observable
   assert "reminder" in build_the_real_way(config).render()
   

   Chimera's own case is worth naming because the class was never broken. Skill cards had a working retriever, a working store and a working injector — and chimera/config.py:244 reads skill_cards: bool = Field(default=False, ...), so on a stock deployment nothing was ever injected. Every unit test passed. The measurement that eventually caught it counted skills minted against skills injected and found 39 against zero.

4. Assert on an observable that can only appear if the component was reached: text in the rendered prompt, a row written, a log line, an exit code.

5. Assert the default. If the feature ships behind a flag, add a separate test that reads the default value with no overrides and asserts what it is. A suite that only ever runs with the flag forced on cannot tell you what users get.

Entrypoint tests are slower, harder to debug, and give worse localisation: when one fails you know the feature is broken but not which of ten components broke it. That is a real cost, and the wrong response to this card is deleting your unit tests in favour of end-to-end ones. Keep both — the wiring test tells you that it broke, the unit test tells you what.

Going through the real entrypoint can also touch things you do not want touched in CI: a paid API, a live database, a filesystem outside the sandbox. If the only way to reach the entrypoint is to spend money or mutate production, do not force it; cover the assembler function directly instead and accept that you are one step short of the true path.

And this card catches reachability, not correctness. A feature can be perfectly wired to the entrypoint and still produce the wrong answer, so a green wiring test is not licence to skip asserting what the output actually says.