Source Projects
The production projects these testing patterns were extracted from -- what each one is, the patterns it contributed, and why a testing approach has to match its deployment target.
Production-Tested Approaches
The patterns in this guide come from real production projects, not theoretical best practices. Each pattern has been used in shipped software and refined through actual bugs and failures.
They are organized into four categories: Tool Patterns for tool- and implementation-specific technique, Project Recipes for patterns shaped by a repo type, CI Operations for running suites across CI, deploys, and releases, and Test Integrity for the ways tests deceive and the discipline that prevents it.
The Projects
| Project | Type | Key Testing Patterns |
|---|---|---|
| zudo-text | Tauri text editor (monorepo) | Vitest unit across workspace packages, Rust cargo test core crate, dual-browser Playwright (Chromium CI / WebKit local), mock backend adapter + console-error monitoring, tiered e2e tags |
| zzmod | Content website (zfb + Preact islands) | Vitest unit (jsdom, Testing Library/Preact, MSW), production-build Playwright, tag-based @smoke/@heavy lanes, CI image interception, heavy E2E off-CI via local b4push |
| pgen | Pattern generator (monorepo + GPU runtime) | Deterministic PNG rendering, Miniflare + D1/R2 worker integration, tag-tiered Playwright e2e, GPU visual-regression (SSIM drift, GLSL parity) |
| mdx-formatter | CLI + npm library (Rust napi) | Contract-testing the Rust engine via Vitest, idempotency invariant, snapshot regression vs committed baselines, CLI integration via execFile |
| zfb | Frontend build orchestrator / SSG | Rust workspace cargo test (primary), binding-shape stubs, emitted-code dynamic import, single-source-of-truth guard, happy-dom router quirks, node-free Docker smoke E2E |
| zudo-doc | Doc-site framework | 6-level test taxonomy (Vitest unit → static dist reads → Playwright multi-fixture E2E → verify-ui), remark/rehype golden-fixture corpus + mdast tree factories |
Common Theme
Across all these projects, one theme emerges: the testing approach must match the deployment target. A web app needs browser-level testing. A CLI tool needs output verification. A Tauri app needs WebKit-specific testing. There is no universal test setup -- only appropriate test setups for specific contexts.