Testing

DocSlime is verified behavior-first: the things a user actually does — scaffold a tree, add a document, create an ADR, list templates — are exercised end-to-end by running the real compiled binary against throwaway directories and asserting on the files it produces. Small, fiddly logic (slug normalization, ADR numbering) is covered by fast unit tests. The bar for shippable is simple: the full suite is green, impeccable can discover docs context, and the binary’s observable behavior matches the experiences and requirements.

Strategy

There is no separate integration layer: the codebase is small and the components are best verified together through the CLI, so the black-box tests double as integration coverage.

Behavior coverage

Traceability contract

DocSlime’s TDD+BDD bar is that every important behavior can be followed from intent to proof:

The DDD evidence is intentionally lightweight: docs should name the domain concepts and boundaries that affect behavior, then use ADRs for hard-to-reverse decisions. If a project has no meaningful domain split, the architecture doc should say that instead of inventing bounded contexts.

Evaluation against product goals

Tests prove correctness; they don’t prove the product is working. The product-level signals from ../PRODUCT.md are evaluated qualitatively:

• Docs get filled — judged by whether scaffolded docs in real repos end up complete (no leftover <!-- LLM: --> guidance), rather than abandoned as templates. DocSlime dogfoods this by filling in its own docs/ tree.
• Low friction — judged by the time and number of steps from docslime init to a first useful, filled-in document.
• Agent context quality — judged by whether agents working in a DocSlime-backed repo give less speculative answers because product context, requirements, and ADRs are present.
• Impeccable context quality — judged by whether impeccable resolves docs/PRODUCT.md and docs/DESIGN.md without duplicate root files.
• Delivery quality — judged by whether each CLI, skill, and site artifact is verified through its user-facing distribution path rather than inferred from workflow completion.
• Production learning — judged by whether release failures, feedback, and adoption signals update discovery evidence or requirements when they reveal a material gap.
• Skill robustness — judged by whether skill files validate structurally and give agents enough setup, guardrails, verification, and failure handling to act without guessing.
• Adoption — tracked via Homebrew and npx skills installs and repos using the tree.

Running the tests

cargo test                  # unit + integration suite (expected: all green)
cargo clippy --all-targets  # lint (expected: no warnings)
npm run build               # docmd site build (expected: site/ output updates cleanly)

Continuous integration

DocSlime is now a monorepo with three CI-owned surfaces:

The daily CI workflow lives in .github/workflows/ci.yml and runs on pull requests to staging or main, pushes to those branches, and manual dispatches. The release workflow (.github/workflows/release.yml, generated by cargo-dist) remains tag-driven: it builds and packages the CLI for all target platforms, creates the GitHub Release, and publishes the Homebrew formula.

GitHub also has an active repository ruleset named “Protect main and staging from deletion”. It targets refs/heads/main and refs/heads/staging with the deletion rule so the two release branches cannot be removed accidentally.

Test data & environments

End-to-end tests run the real binary inside a fresh tempfile::TempDir per test, so each one gets an isolated throwaway directory that is cleaned up automatically — no shared state, no fixtures to seed, and no risk of touching the working repo.