cubeplex TDD
The test-first loop for cubeplex. This skill is the loop and the judgment — it does not restate the test rules. For what earns a test's place, the layer split, directory placement, real-services / real-LLM discipline, no-sleep / cleanup rules, and the "would this catch the bug?" check, read the authoritative source: docs/testing.md. Don't duplicate it here.
When TDD is the default
Feature work, business logic, reusable core behavior, and bug fixes where the behavior keeps evolving — the red→green loop is strongest when the test can express a stable contract future changes must preserve. Use judgment for one-off migrations / config / docs / mechanical rewrites (validate with the smallest realistic reproduction instead) — but always verify with a real command regardless.
The loop
- Red. Write the smallest test expressing a stable business invariant or contract (testing.md: "would this catch the bug?"). Watch it fail for the right reason — an assertion, not an import error.
- Green. Minimal code to pass.
- Refactor. Clean up with the test as the safety net.
The one placement rule you can't get wrong
The full taxonomy is in testing.md; this is the footgun worth repeating: if
the test opens an AsyncSession, runs alembic, or hits the FastAPI app, it is
an e2e test (backend/tests/e2e/) — full stop. Misplacing it into
integration/ makes it run on every pre-push and fail the suite. Everything
else → testing.md's "pick the directory by what the test hits".
Running
bashmake backend-test-e2e # backend e2e make backend-test-contracts # plugin/EE contract tests make test-ui-unit # frontend unit make frontend-test-e2e # frontend Playwright (writing/debugging → /playwright-cli)
Per task, run only the changed-module tests; the pre-push hook runs the
CI-equivalent make check-ci when you push code.
