# Testing Tdd

> TDD workflow and testing strategy for code implementation. Use when writing tests, implementing features that need tests, or fixing bugs. Defines Red-Green-Refactor gates, integration-first strategy, and test coverage requirements.

- Skill: `est7/testing-tdd` (Agent Skill)
- Install (CLI): `npx skillmds@latest add est7/testing-tdd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/est7/testing-tdd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: est7 (https://skillmd.com/u/est7)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/est7/testing-tdd

---


# Testing & TDD Workflow

## Core Constraints (always apply)

* Every implementation must include a test plan or verification method.
* **Coverage**: happy path + boundary conditions + error recovery.
* **Test naming**: clearly describe the scenario, e.g., `test_login_with_invalid_password_returns_401`.
* For non-trivial logic changes: prefer adding or updating tests.
* When tests are missing, state the reason and a follow-up test plan.

---

## Observation & Honesty

* Report only what you can directly observe.
* If you can run tests in the current environment: run them and report actual results.
* If you cannot run tests: provide exact commands, expected failure points, and wait for user to confirm results before proceeding.
* Never fabricate or assume test results.

---

## TDD Gate (for non-trivial implementations)

Strict Red-Green-Refactor cycle:

1. **Red**: Write tests first that define expected behavior and boundary conditions.
2. **Review**: For **complex / high-risk** tasks, tests must be reviewed by the user before proceeding (moderate tasks: review is recommended).
3. **Confirm Red**: Verify tests fail with current implementation (run or provide commands for user to confirm).
4. **Green**: Write minimum implementation to make tests pass.
5. **Refactor**: Clean up without changing behavior.

**Complexity gating:**

- **trivial** tasks (one-line fix, simple config): TDD gate is optional. Provide verification method instead.
- **moderate** tasks: TDD gate recommended. Write test → implement → verify.
- **complex** tasks: TDD gate mandatory. Full Red-Green-Refactor cycle.
- **Bug fixes** (all levels): Always write a failing test that reproduces the bug first, then fix.

---

## Integration-First Strategy

Test priority order:

1. **Real environment first**: use real database, actual service instances when available.
2. **Contract tests**: define contracts (input/output/error semantics) and write contract tests before implementation.
3. **Mocks only when necessary**: if mock/stub is unavoidable, document:
   * Why real boundary is not available
   * What real-world coverage is missing
   * Compensating strategy (e.g., additional E2E test or smoke verification)

---

## BDD Fallback (E2E unavailable)

When the runtime cannot launch E2E tests (no browser automation, no real service instances, no CI):
* **complex** tasks → produce Gherkin `.feature` scenarios (mandatory)
* **moderate** tasks with cross-boundary behavior → Gherkin `.feature` recommended
* `.feature` files use standard Gherkin syntax (`Feature` / `Scenario` / `Given` / `When` / `Then`) and serve as executable specs for later Cucumber/Behave wiring

---

## Deliverables

For each implementation, testing deliverables include:

* Tests (unit + integration/contract as appropriate)
* Gherkin `.feature` scenarios when E2E is unavailable or behavior needs end-to-end coverage
* Runnable verification commands (or user-side reproduction steps + expected output)
* Exception notes if any gate was skipped (with risk and compensating strategy)