AgentSkillsCN

Tdd Workflow

如何采用测试驱动开发（红-绿-重构）实现功能

SKILL.md
--- frontmatter
description: How to implement features using Test Driven Development (Red-Green-Refactor)

TDD Workflow

Skill for implementing features using the TDD cycle: Red → Green → Refactor.

Input

  • •A ticket with User Story, Acceptance Criteria, and Definition of Done

Output

  • •Production code + Tests that validate the acceptance criteria

The TDD Cycle

code
┌─────────┐     ┌─────────┐     ┌──────────┐
│  🔴 RED  │────▶│ 🟢 GREEN│────▶│ 🔵 REFACT│
│ Write    │     │ Write    │     │ Clean    │
│ test that│     │ MINIMUM  │     │ code     │
│ FAILS    │     │ code to  │     │ without  │
│          │     │ pass     │     │ breaking │
│          │     │          │     │ tests    │
└─────────┘     └─────────┘     └──────┬───┘
     ▲                                 │
     └─────────────────────────────────┘
              Next test

Process Per Ticket

1. Read the Ticket

  • •Read the Acceptance Criteria — each one is a test
  • •Read the technical notes — how to implement

2. Plan Tests

Before writing code, list the tests you need:

markdown
Planned tests for [TICKET_ID]:
- [ ] Test 1: [Acceptance criterion 1]
- [ ] Test 2: [Acceptance criterion 2]
- [ ] Test 3: [Edge case: empty input]
- [ ] Test 4: [Edge case: invalid data]

3. Red-Green-Refactor Cycle

For each planned test:

🔴 RED:

code
1. Write the test
2. Run → MUST FAIL
3. If it passes without new code → test is useless, rewrite

🟢 GREEN:

code
1. Write MINIMUM code to make the test pass
2. Don't optimize, don't beautify
3. Run → MUST PASS

🔵 REFACTOR:

code
1. Clean code (naming, DRY, structure)
2. Run tests → MUST STILL PASS
3. If something breaks, revert and retry

4. Verify Completeness

After finishing all tests for the ticket:

  • •□ All acceptance criteria have a test
  • •□ Edge cases covered (nulls, empty, boundaries)
  • •□ All tests pass
  • •□ Code is clean (post-refactor)
  • •□ No lint warnings

What to Test vs Not Test

✅ Test❌ Don't Test
Business logicTrivial getters/setters
ValidationsFramework internals
Data transformationsUI layout
Edge casesThird-party libraries
Error handlingConstants

Test Structure

code
src/
├── main/
│   └── feature/
│       └── FeatureClass.kt
└── test/
    └── feature/
        └── FeatureClassTest.kt    ← Test next to code

Naming Convention

code
fun `should [expected behavior] when [condition]`()

// Examples:
fun `should return empty list when no items match filter`()
fun `should throw exception when input is null`()
fun `should calculate total with tax included`()

Rules

  1. •NEVER write production code without a failing test first
  2. •NEVER create separate tickets or tasks for tests
  3. •NEVER skip tests to "save time"
  4. •ALWAYS run the full suite before marking as done
  5. •ALWAYS cover at least 1 happy path + 1 edge case per criterion