Help us improve
Share bugs, ideas, or general feedback.
From quorum
Generates test strategy guides for project tracks, defining coverage targets, test levels (unit, integration, E2E), frameworks, environments, tools, risk priorities, and dependencies.
npx claudepluginhub berrzebb/quorum --plugin quorumHow this agent operates — its isolation, permissions, and tool access model
Agent reference
quorum:agents/knowledge/references/planner/test-strategyThe summary Claude sees when deciding whether to delegate to this agent
The test strategy defines the **testing approach for a track** — what levels of testing, what coverage targets, what environments, and what tools. It bridges the gap between individual WB test items and the project's overall quality goals. `{planning_dir}/{track-name}/test-strategy.md` — one per track, optional (only for tracks with significant testing needs). - Track has 3+ WB items with test ...Expert C++ code reviewer that runs git diff, clang-tidy, and cppcheck on modified files. Focuses on memory safety, modern C++ idioms, concurrency, and performance.
Share bugs, ideas, or general feedback.
The test strategy defines the testing approach for a track — what levels of testing, what coverage targets, what environments, and what tools. It bridges the gap between individual WB test items and the project's overall quality goals.
{planning_dir}/{track-name}/test-strategy.md — one per track, optional (only for tracks with significant testing needs).
Do NOT write for simple tracks where WB-level test descriptions are sufficient.
# Test Strategy: {Track Name}
## Coverage Targets
| Metric | Target | Current | Method |
|--------|--------|---------|--------|
| Statement coverage | ≥ 85% | 62% | test runner `--coverage` |
| Branch coverage | ≥ 75% | 48% | test runner `--coverage` |
| Changed file coverage | 100% files have tests | — | RTM forward matrix |
## Test Levels
### Unit Tests
- **Scope**: Individual functions and classes
- **Framework**: (project test runner — e.g. vitest, pytest, cargo test)
- **Location**: `tests/{module}/*.test.*`
- **Naming**: `test_{subject}_{scenario}_{expected}`
### Integration Tests
- **Scope**: Cross-module interactions, API endpoints
- **Framework**: (project test runner + HTTP client)
- **Location**: `tests/integration/*.test.ts`
- **Setup**: Mock server via `createMockServer()` helper
### E2E Tests (if applicable)
- **Scope**: Full user flows through UI
- **Framework**: Playwright
- **Location**: `web/e2e/*.test.ts`
- **Environment**: Requires running dev server
## Test Data
- **Fixtures**: `tests/fixtures/` — static test data files
- **Factories**: `tests/helpers/factories.ts` — dynamic test data generators
- **Mock server**: `tests/helpers/mock-server.ts` — configurable HTTP mock
## Risk-Based Priorities
| Risk Area | Test Focus | WB Items |
|-----------|-----------|----------|
| Auth bypass | Negative auth tests for every new endpoint | OR-3, OR-5 |
| Data corruption | Transaction rollback tests | OR-2 |
| UI regression | Snapshot tests for changed components | FE-1, FE-3 |
## Dependencies
- External services to mock: Redis, PostgreSQL, external APIs
- Test environment requirements: Node.js 20+, Docker (for integration)
- CI considerations: parallel test execution, flaky test quarantine