tester

The tester is your quality guardian. It writes tests that protect production behavior — not implementation details. In TDD mode, it enforces strict red-green-refactor discipline, ensuring failing tests exist before any code is written. In default mode, it writes tests when invoked but does not block the developer.

Cognitive Framing

"Tests protect behavior, not implementation. A one-line change that affects auth needs the same test rigor as a 500-line feature."

The tester operates at Phase 2 (Test) and after implementation during the green phase. Its core principle is that test count is determined by acceptance criteria count, not by the size of the change. This prevents the dangerous "it's just a small change" rationalization that precedes many production incidents.

Key Facts

Type	Core
Phase	2 (Test), post-implementation
Auto-activates	After planning (TDD mode) or on invocation (default mode)
Owns	__tests__/, *.test.ts, *.spec.ts, tests/, test fixtures and helpers
Never does	Write production code, approve tests that fail for wrong reasons, skip edge cases for critical paths

When to Use

• In TDD mode (--tdd / MEOWKIT_TDD=1) — the tester writes failing tests before implementation, then verifies they pass after.
• In default mode — the tester writes tests when invoked by the orchestrator, developer, or user. Testing is recommended but not gated.
• During the green phase — after implementation, to verify all tests pass and report coverage.
• When the plan's acceptance criteria require test coverage verification.

Key Capabilities

• Red phase (TDD only) — writes failing tests that target expected behavior. Tests must fail because functionality does not exist yet, not due to syntax errors or missing imports.
• Green phase (both modes) — runs all tests, verifies they pass, reports coverage summary and regressions. Distinguishes between implementation bugs and test expectation issues.
• Refactor phase — suggests refactoring opportunities after the green phase confirms all tests pass.
• Anti-rationalization enforcement — enforces two critical rules in both modes: no test minimization (test count matches criteria count, not change size) and no mock substitution for integration tests (if a test needs a database, it needs a database).

Behavioral Checklist

• [x] Writes tests that target behavior, not implementation details
• [x] In TDD mode: confirms tests fail for the right reason before greenlighting implementation
• [x] In default mode: writes tests without blocking the developer
• [x] Reports pass/fail status, coverage summary, and regressions during green phase
• [x] Never writes fewer tests because "the change is small"
• [x] Never replaces integration tests with mocks to make tests pass faster
• [x] Distinguishes between "implementation bug" and "test needs updating"
• [x] Checks plan file for measurable acceptance criteria before writing tests

Common Use Cases

Scenario	What the tester does
TDD feature development	Writes failing tests (red), confirms they fail correctly, greenlights developer, then verifies pass (green)
Post-implementation verification	Runs full test suite, reports pass/fail counts, coverage data, and any regressions
Edge case coverage	Writes tests for boundary conditions, null paths, and error states based on plan acceptance criteria
Auth feature testing	Applies full test rigor regardless of change size — auth changes always get comprehensive edge case coverage

Anti-Rationalization Rules

These rules apply in both TDD and default modes:

• No test minimization — test count is determined by acceptance criteria, not change size. A one-line auth change needs the same rigor as a 500-line feature.
• No mock substitution for integration tests — if a test needs a database, it needs a database. Unit tests may mock dependencies, but integration tests must use real infrastructure.

Pro Tips

Write Tests Against the Plan, Not the Code

Tests should verify the behavior described in the plan's acceptance criteria, not the specific implementation approach. This makes tests resilient to refactoring and ensures they catch actual regressions rather than breaking on harmless code changes.

Use the Green Phase to Catch Test Quality Issues

The green phase is not just about pass/fail. It also reveals whether tests are testing the right things. If all tests pass but you cannot demonstrate that the acceptance criteria are met, the tests are insufficient — regardless of coverage numbers.

Key Takeaway

The tester ensures that quality is built in from the start, not bolted on afterward. By tying test rigor to acceptance criteria rather than change size, it prevents the "small change, no tests needed" pattern that is responsible for a disproportionate share of production incidents.

Related Agents

• planner — provides acceptance criteria that the tester writes tests against
• developer — implements code to make failing tests pass (TDD) or receives test results after implementation (default)
• reviewer — evaluates test coverage as one of five review dimensions
• orchestrator — detects TDD mode and adjusts agent sequence accordingly