Claude Code Plugins

Community-maintained marketplace

Feedback

generating-tdd-tests

@thkt/claude-config
3
0

>

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

name generating-tdd-tests
description TDD with RGRC cycle and Baby Steps methodology. Triggers: TDD, テスト駆動開発, Red-Green-Refactor, Baby Steps, test generation, テスト生成, テスト設計, テストケース, boundary value, 境界値分析, coverage, カバレッジ, unit test
allowed-tools Read, Write, Edit, Grep, Glob, Task

TDD Test Generation

Purpose

Systematic Test-Driven Development combining RGRC cycle, Baby Steps, and test design techniques.

Baby Steps - 2-Minute Cycle

"Make the smallest possible change at each step" - t_wada

Step Time Action
1 30s Write smallest failing test
2 1min Make it pass minimally
3 10s Run tests
4 30s Tiny refactor (if needed)
5 20s Commit if green

Why: Bug is always in last 2-minute change. Always seconds from green.

RGRC Checklist

Copy and track progress:

TDD Cycle:
- [ ] Red - 失敗するテスト作成 (verify correct failure reason)
- [ ] Green - 最小限のコードで通過 (dirty OK)
- [ ] Refactor - コード改善 (keep tests green)
- [ ] Commit - 変更をコミット (all checks pass)

Phase Details

Phase Goal Rule
Red Failing test Verify failure reason is correct
Green Pass test "You can sin" - quick/dirty OK
Refactor Clean code Apply SOLID/DRY, keep green
Commit Save state All checks pass

Test Design Techniques

Technique Use For Example
Equivalence Partitioning Group inputs with same behavior Age: <18, 18-120, >120
Boundary Value Test edges 17, 18, 120, 121
Decision Table Complex multi-condition logic isLoggedIn × isPremium → access

Coverage Goals

Level Target Focus
C0 (Statement) 80% All lines executed
C1 (Branch) 70% All branches taken

Why these targets: Cost-benefit balance, focus on critical paths.

AAA Pattern

test('descriptive name', () => {
  // Arrange - Setup
  // Act - Execute
  // Assert - Verify
})

When NOT to Use TDD

  • Prototypes (throwaway code)
  • External API integration (use mocks)
  • Simple one-off scripts
  • UI experiments (visual first)

Test Priority Matrix

Not everything needs to be tested. Prioritize by impact.

✅ Must Test (Priority 1)

  • Business Logic: Calculations, validation, state transitions
  • Service/Repository Layer: Data operations beyond simple CRUD
  • Critical Paths: Billing, authentication, data persistence
  • Edge Cases: Boundary values, null/undefined, empty arrays

🟡 Situational (Priority 2)

  • Utility Functions: Only complex ones
  • Custom Hooks: State management logic portion
  • Transformations: Complex mapping/formatting

❌ Skip Testing

  • Simple property accessors/getters
  • UI layout/styling
  • External library behavior verification
  • Prototype/experimental code
  • Simple CRUD (framework-provided)
  • Config file loading

Decision Criteria: "If this logic breaks, will it impact users?"

Naming Convention (Jest/Vitest)

Consistent naming makes test intent clear.

Recommended Pattern

describe('[TargetClass/FunctionName]', () => {
  describe('[MethodName/Scenario]', () => {
    it('when [condition], should [expected result]', () => {
      // Arrange - Act - Assert
    })
  })
})

Examples

describe('PriceCalculator', () => {
  describe('calculateTotal', () => {
    it('when empty array, should return 0', () => {
      expect(calculator.calculateTotal([])).toBe(0)
    })

    it('when discount code applied, should return discounted total', () => {
      const items = [{ price: 1000, quantity: 2 }]
      expect(calculator.calculateTotal(items, 'SAVE10')).toBe(1800)
    })

    it('when tax included, should return total with correct tax', () => {
      const items = [{ price: 1000, quantity: 1 }]
      expect(calculator.calculateTotal(items, null, { includeTax: true })).toBe(1100)
    })
  })
})

Naming Guidelines

Element Good Bad
Condition when empty array test1
Expected should return 0 works correctly
Context when discount applied discount

Tip: Use descriptive names that serve as documentation

References

Principles (rules/)

Skill References

Related Skills

  • tdd-fundamentals - TDD基本原則
  • applying-code-principles - コード原則適用

Used by Commands

  • /code - TDD実装サイクル
  • /fix - バグ修正のリグレッションテスト
  • /test - テスト実行・検証