Default test-runner for the Tier 1 verify loop. Shells out to the project's own Kaocha runner in the current working directory and parses the result.
Why shell out rather than run in-process: Kaocha exposes no stable
programmatic API, and the affected tests must run in the project's full
classpath (H2, the module under test, fixtures) — not the MCP server's. The
runner is injected into the tool deps as :test-runner, so this is swappable
(and stubbed in unit tests).
The structured parse is best-effort over Kaocha's textual output; the raw output tail is always included so the agent has the real failure text even when a failure shape isn't recognized.
Default test-runner for the Tier 1 verify loop. Shells out to the project's own Kaocha runner in the current working directory and parses the result. Why shell out rather than run in-process: Kaocha exposes no stable programmatic API, and the affected tests must run in the *project's* full classpath (H2, the module under test, fixtures) — not the MCP server's. The runner is injected into the tool deps as `:test-runner`, so this is swappable (and stubbed in unit tests). The structured parse is best-effort over Kaocha's textual output; the raw output tail is always included so the agent has the real failure text even when a failure shape isn't recognized.
(default-test-runner module)(default-test-runner module
{:keys [command root]
:or {root (System/getProperty "user.dir")}})Run the project's tests for module and return a structured result:
{:status :passed | :failed | :error | :no-tests
[:passed n] [:failed n] [:failures [{:var :file :line :message}]]
[:note str] :raw-tail str}
:error means the runner could not run the tests — distinct from :failed
(tests ran, some failed) and from :no-tests (the module has none).
Run the project's tests for `module` and return a structured result:
{:status :passed | :failed | :error | :no-tests
[:passed n] [:failed n] [:failures [{:var :file :line :message}]]
[:note str] :raw-tail str}
`:error` means the runner could not run the tests — distinct from `:failed`
(tests ran, some failed) and from `:no-tests` (the module has none).(test-command root module)How to run module's tests in the project at root: {:argv [...]}, or
{:no-tests true} when the module has none.
A suite with the module's id (the framework repo, one per library) runs by
id. A generated project has only :unit and :integration, and bb scaffold integrate adds no suite by design, so -M:test :<module> answered "No such
suite", exit 254, forever — reported as "not wired yet" even for an
integrated module (BOU-520). There the module's test namespaces are focused
instead.
How to run `module`'s tests in the project at `root`: `{:argv [...]}`, or
`{:no-tests true}` when the module has none.
A suite with the module's id (the framework repo, one per library) runs by
id. A generated project has only :unit and :integration, and `bb scaffold
integrate` adds no suite by design, so `-M:test :<module>` answered "No such
suite", exit 254, forever — reported as "not wired yet" even for an
integrated module (BOU-520). There the module's test namespaces are focused
instead.cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |