Test
Writes tests and enforces TDD (RED-GREEN-REFACTOR), analyzes coverage gaps, and defines test strategy across Python, TypeScript, .NET, Rust, and Go. Use it to add or plan tests; for failing tests where the fix is unclear use /ai-debug, and for AI reliability over time use /ai-reliability-eval.
Purpose
TDD enforcement and testing. Tests are executable specifications — they define what the system does before the system does it. Maximum confidence per minute of developer time.
Workflow
Principles applied: §10.5 TDD (tests are executable specifications; RED-GREEN-REFACTOR drives new code).
Step 0 — load contexts: read .ai-engineering/manifest.yml providers.stacks; load .ai-engineering/overrides/<stack>/conventions.md per stack + .ai-engineering/overrides/_shared/conventions.md; load .ai-engineering/team/*.md.
| Mode |
Steps |
tdd |
Follow handlers/tdd.md for the full RED-GREEN-REFACTOR flow. |
run |
1. detect framework from project files. 2. follow existing conventions (dirs, naming, fixtures). 3. write tests AAA-style with descriptive names. 4. run with the stack command. 5. report pass/fail count + coverage delta. |
gap |
1. run coverage with branch coverage on. 2. identify untested critical paths (business logic > glue). 3. check missing edge cases: null, empty, boundary, error. 4. produce a prioritized gap report. |
plan |
1. map the testing surface (modules, public APIs, critical paths). 2. assign categories: unit, integration, e2e. 3. set coverage targets per module. 4. identify infra needs (containers, fixtures, fakes). |
Stack Commands
| Stack |
Runner |
Coverage |
Async |
| Python |
uv run pytest |
pytest-cov (branch=true) |
asyncio_mode = "auto" |
| TypeScript |
vitest or jest |
c8 / istanbul |
async/await |
| .NET |
dotnet test + xUnit |
coverlet |
async Task |
| Rust |
cargo test |
cargo tarpaulin |
#[tokio::test] |
| Go |
go test ./... |
go test -cover |
goroutine tests |
Testing Rules
- Fakes over mocks — mocks test implementation details; fakes implement the same interface. Mocks are acceptable ONLY for: (1) verifying something was NOT called, (2) simulating transient errors for retry logic, (3) third-party libraries (wrap in your own adapter first).
- AAA pattern (non-negotiable) — Arrange (inputs + deps), Act (call the unit), Assert (verify the outcome).
- Name pattern —
test_<unit>_<scenario>_<expected_outcome>. Good: test_parse_email_rejects_missing_at_symbol. Bad: test_parse_email, test_1, test_it_works.
Anti-Patterns (Reject These)
| Anti-Pattern |
Why It Fails |
| Testing the mock |
Proves the mock works, not the code |
| No-op test (assert True) |
Tests nothing, inflates coverage |
| Testing implementation |
Breaks on refactor, proves nothing about behavior |
| Huge test setup |
Design is too coupled — simplify the interface |
| sleep() for sync |
Flaky — use events, barriers, wait_for |
| Exact float comparison |
Flaky — use approx/closeTo |
Iron Law
If tests are wrong, escalate to the user. NEVER weaken, skip, or modify tests to make implementation easier — tests are the contract; bending them hides bugs. "Tests are wrong" means the requirement changed, not that passing them is hard.
Common Mistakes
- Writing tests after implementation (tests-after prove what IS, not what SHOULD be).
- Testing private methods (test the public API).
- Not running ALL tests after changes.
Handlers
| Handler |
File |
Activation |
| E2E Testing |
handlers/e2e.md |
*.spec.ts, playwright.config.ts, or e2e/ detected |
| TDD Mode |
handlers/tdd.md |
mode=tdd |
Examples
Example — TDD a new feature
User: "I'm building a JWT validator. Walk me through TDD."
/ai-test tdd jwt-validator
RED: writes failing tests for valid token, expired token, malformed signature; confirms FAIL for the expected reason. GREEN: hands off to ai-build for minimal implementation. REFACTOR: stays green.
Integration
Called by: /ai-build (build + TDD tasks), user directly. Calls: stack-specific test runners. See also: /ai-debug, /ai-verify, /ai-reliability-eval.
$ARGUMENTS
1---2name: ai-test3description: Writes tests, enforces TDD (RED-GREEN-REFACTOR), analyzes coverage gaps, defines test strategy across Python, TypeScript, .NET, Rust, Go. Trigger for 'add tests for', 'write a test', 'I need 80 percent coverage', 'plan my test approach', 'TDD this'. Not for failing tests where the fix is unclear; use /ai-debug instead. Not for AI reliability over time; use /ai-reliability-eval instead.4---56# Test78Writes tests and enforces TDD (RED-GREEN-REFACTOR), analyzes coverage gaps, and defines test strategy across Python, TypeScript, .NET, Rust, and Go. Use it to add or plan tests; for failing tests where the fix is unclear use /ai-debug, and for AI reliability over time use /ai-reliability-eval.910## Purpose1112TDD enforcement and testing. Tests are executable specifications — they define what the system does before the system does it. Maximum confidence per minute of developer time.1314## Workflow1516Principles applied: §10.5 TDD (tests are executable specifications; RED-GREEN-REFACTOR drives new code).1718Step 0 — load contexts: read `.ai-engineering/manifest.yml` `providers.stacks`; load `.ai-engineering/overrides/<stack>/conventions.md` per stack + `.ai-engineering/overrides/_shared/conventions.md`; load `.ai-engineering/team/*.md`.1920| Mode | Steps |21| --- | --- |22| `tdd` | Follow `handlers/tdd.md` for the full RED-GREEN-REFACTOR flow. |23| `run` | 1. detect framework from project files. 2. follow existing conventions (dirs, naming, fixtures). 3. write tests AAA-style with descriptive names. 4. run with the stack command. 5. report pass/fail count + coverage delta. |24| `gap` | 1. run coverage with branch coverage on. 2. identify untested critical paths (business logic > glue). 3. check missing edge cases: null, empty, boundary, error. 4. produce a prioritized gap report. |25| `plan` | 1. map the testing surface (modules, public APIs, critical paths). 2. assign categories: unit, integration, e2e. 3. set coverage targets per module. 4. identify infra needs (containers, fixtures, fakes). |2627## Stack Commands2829| Stack | Runner | Coverage | Async |30|-------|--------|----------|-------|31| Python | `uv run pytest` | `pytest-cov` (branch=true) | `asyncio_mode = "auto"` |32| TypeScript | `vitest` or `jest` | `c8` / `istanbul` | `async/await` |33| .NET | `dotnet test` + xUnit | `coverlet` | `async Task` |34| Rust | `cargo test` | `cargo tarpaulin` | `#[tokio::test]` |35| Go | `go test ./...` | `go test -cover` | goroutine tests |3637## Testing Rules3839- **Fakes over mocks** — mocks test implementation details; fakes implement the same interface. Mocks are acceptable ONLY for: (1) verifying something was NOT called, (2) simulating transient errors for retry logic, (3) third-party libraries (wrap in your own adapter first).40- **AAA pattern** (non-negotiable) — Arrange (inputs + deps), Act (call the unit), Assert (verify the outcome).41- **Name pattern** — `test_<unit>_<scenario>_<expected_outcome>`. Good: `test_parse_email_rejects_missing_at_symbol`. Bad: `test_parse_email`, `test_1`, `test_it_works`.4243## Anti-Patterns (Reject These)4445| Anti-Pattern | Why It Fails |46|-------------|-------------|47| Testing the mock | Proves the mock works, not the code |48| No-op test (assert True) | Tests nothing, inflates coverage |49| Testing implementation | Breaks on refactor, proves nothing about behavior |50| Huge test setup | Design is too coupled — simplify the interface |51| sleep() for sync | Flaky — use events, barriers, wait_for |52| Exact float comparison | Flaky — use approx/closeTo |5354## Iron Law5556If tests are wrong, escalate to the user. NEVER weaken, skip, or modify tests to make implementation easier — tests are the contract; bending them hides bugs. "Tests are wrong" means the requirement changed, not that passing them is hard.5758## Common Mistakes5960- Writing tests after implementation (tests-after prove what IS, not what SHOULD be).61- Testing private methods (test the public API).62- Not running ALL tests after changes.6364## Handlers6566| Handler | File | Activation |67|---------|------|-----------|68| E2E Testing | `handlers/e2e.md` | `*.spec.ts`, `playwright.config.ts`, or `e2e/` detected |69| TDD Mode | `handlers/tdd.md` | `mode=tdd` |7071## Examples7273### Example — TDD a new feature7475User: "I'm building a JWT validator. Walk me through TDD."7677```78/ai-test tdd jwt-validator79```8081RED: writes failing tests for valid token, expired token, malformed signature; confirms FAIL for the expected reason. GREEN: hands off to `ai-build` for minimal implementation. REFACTOR: stays green.8283## Integration8485Called by: `/ai-build` (build + TDD tasks), user directly. Calls: stack-specific test runners. See also: `/ai-debug`, `/ai-verify`, `/ai-reliability-eval`.8687$ARGUMENTS
arcasilesgroup