本文へ移動
cccskills
無料GitHub で公開

tdd-developer

This skill should be used when developing code using Test-Driven Development (TDD) methodology. Use this skill when the user wants to write tests first before implementation, needs guidance on the red-green-refactor cycle, or explicitly requests TDD-style development. Triggers include requests like "develop this feature using TDD", "write tests first", "help me with test-driven development", or "implement this following TDD practices". The skill guides through writing failing tests, implementing minimal code to pass, and refactoring while maintaining test coverage.

インストール方法を見る

含まれるファイル(3)

  • SKILL.md8.0 KB
  • references/tdd_methodology.md5.8 KB
  • references/test_patterns.md6.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

TDD Developer

Overview

This skill provides comprehensive guidance for Test-Driven Development, a methodology where tests are written before implementation code. TDD promotes better design, higher code quality, and fewer defects through the disciplined practice of the red-green-refactor cycle.

When to Use This Skill

  • User explicitly requests TDD or test-first development
  • Building new features that require high reliability
  • Refactoring legacy code with test coverage
  • Implementing complex business logic
  • Learning TDD methodology

TDD Development Workflow

Phase 1: Understand Requirements

Before writing any test:

  1. Clarify the feature requirements with the user
  2. Break down the feature into small, testable behaviors
  3. Identify edge cases and error conditions
  4. Create a list of test cases to implement

Ask clarifying questions such as:

  • "What specific behavior should this function have?"
  • "What should happen when input is invalid?"
  • "Are there any edge cases to consider?"

Phase 2: Red-Green-Refactor Cycles

For each test case, follow this cycle:

Step 1: RED - Write a Failing Test

  1. Write a small, focused test (3-5 lines)
  2. Use the Arrange-Act-Assert pattern:
    • Arrange: Set up test data and dependencies
    • Act: Execute the behavior under test
    • Assert: Verify the expected outcome
  3. Run the test to confirm it fails
  4. Verify it fails for the right reason (not syntax errors)
def test_calculate_discount_for_premium_member():
    # Arrange
    calculator = PriceCalculator()
    member = Member(tier="premium")
    price = 100.0

    # Act
    result = calculator.calculate_discount(price, member)

    # Assert
    assert result == 20.0  # 20% discount

Step 2: GREEN - Make the Test Pass

  1. Write the minimum code to pass the test
  2. "Quick and dirty" is acceptable at this stage
  3. Even hard-coded values are fine initially
  4. Focus only on making the current test green
def calculate_discount(self, price, member):
    if member.tier == "premium":
        return price * 0.20
    return 0

Step 3: REFACTOR - Improve the Code

  1. Review the implementation for improvements
  2. Apply refactoring techniques:
    • Remove duplication (DRY)
    • Extract methods/functions
    • Improve naming
    • Simplify logic
  3. Run tests after each refactoring to ensure they still pass
def calculate_discount(self, price, member):
    discount_rates = {
        "premium": 0.20,
        "gold": 0.15,
        "silver": 0.10,
        "standard": 0.05,
    }
    rate = discount_rates.get(member.tier, 0)
    return price * rate

Step 4: COMMIT (Optional RGRC Pattern)

After each successful cycle, commit the changes:

  • Creates frequent save points
  • Easy to revert if needed
  • Clear commit history

Phase 3: Iterate Until Complete

  1. Select the next test case from the list
  2. Repeat the red-green-refactor cycle
  3. Continue until all behaviors are implemented
  4. Review overall design and architecture

Test Design Guidelines

Test Naming

Use descriptive names that communicate intent:

  • should_return_zero_when_list_is_empty
  • givenPremiumMember_whenCalculateDiscount_thenReturns20Percent
  • createUser_withValidInput_savesToDatabase

Test Structure

Each test should:

  • Test one behavior only
  • Be independent from other tests
  • Be deterministic (same result every run)
  • Execute quickly

Edge Cases to Cover

Always consider:

  • Empty collections
  • Null/None values
  • Boundary values (0, -1, max)
  • Invalid inputs
  • Error conditions

Parameterized Tests

For similar test cases with different values:

@pytest.mark.parametrize("tier,expected_rate", [
    ("premium", 0.20),
    ("gold", 0.15),
    ("silver", 0.10),
    ("standard", 0.05),
])
def test_discount_rates(tier, expected_rate):
    member = Member(tier=tier)
    result = calculator.calculate_discount(100, member)
    assert result == expected_rate * 100

Implementation Strategies

Triangulation

When implementation is unclear:

  1. Start with one example, hard-code the result
  2. Add second example that forces generalization
  3. Continue until the pattern emerges

Fake It Till You Make It

  1. Return constants to pass tests quickly
  2. Gradually replace with real implementation
  3. Let tests drive the design

Obvious Implementation

When solution is clear:

  1. Implement directly
  2. If it fails, fall back to triangulation

Test Framework Selection

Select the appropriate framework based on language:

  • Python: pytest (recommended), unittest
  • JavaScript/TypeScript: Jest, Vitest
  • Java: JUnit 5, TestNG
  • Ruby: RSpec, minitest
  • Go: testing (built-in)
  • C#: xUnit, NUnit

Quality Principles

Avoid Common Pitfalls

  1. Don't write tests after code - Defeats TDD purpose
  2. Don't skip refactoring - Accumulates technical debt
  3. Don't over-mock - Tests become brittle
  4. Don't test implementation details - Test behavior instead
  5. Don't chase 100% coverage - Focus on meaningful coverage

Test Quality Indicators

  • Tests run fast (<1 second per test)
  • No flaky tests
  • Clear failure messages
  • Test-to-code ratio around 1:1

Resources

References

For detailed methodology and patterns, load these reference files as needed:

  • references/tdd_methodology.md: Complete TDD methodology including the Three Laws of TDD, Red-Green-Refactor cycle details, cycle timing, and common pitfalls to avoid

  • references/test_patterns.md: Test patterns and techniques including triangulation, parameterized tests, test data builders, mocking patterns, and async testing

When to Load References

Load tdd_methodology.md when:

  • User asks about TDD principles or best practices
  • Need to explain the Three Laws or cycle timing
  • Addressing questions about test quality or metrics

Load test_patterns.md when:

  • User needs specific test patterns (builders, mocking)
  • Implementing parameterized or property-based tests
  • Dealing with async testing scenarios

Example TDD Session

User request: "Create a function to validate email addresses using TDD"

Step 1: Plan Test Cases

Test cases for email validation:
1. Valid email returns true
2. Missing @ returns false
3. Missing domain returns false
4. Missing local part returns false
5. Multiple @ symbols returns false
6. Empty string returns false
7. None/null returns false

Step 2: First Cycle - Valid Email

RED:

def test_valid_email_returns_true():
    result = validate_email("user@example.com")
    assert result is True

GREEN:

def validate_email(email):
    return True  # Minimal implementation

REFACTOR: No changes needed yet.

Step 3: Second Cycle - Missing @

RED:

def test_missing_at_symbol_returns_false():
    result = validate_email("userexample.com")
    assert result is False

GREEN:

def validate_email(email):
    return "@" in email

REFACTOR: Still simple, no changes needed.

Step 4: Continue Cycles

Continue through remaining test cases, letting the implementation emerge from the tests. The final implementation will be well-tested and handle all edge cases.

Summary

  1. Write test first - Always before implementation
  2. Keep cycles short - ~1-2 minutes per cycle
  3. Minimal code - Just enough to pass
  4. Refactor always - Never skip this step
  5. Test behavior - Not implementation details
  6. Commit frequently - After each green-refactor

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

action-status-updater

無料日本語概要

Track and update action item status from natural language updates like 'Seanのメールには返信しておいた' or 'Lu対応予定'. Integrates with daily-comms-ops workflow. Use when managing action items across communication channels.

takusaotome/claude-skills-library92026年10月5日 更新

ai-adoption-consultant

無料日本語概要

AI活用提案の専門コンサルタントスキル。LLM・AIエージェントの活用事例知識を基に、業界別、部門別、シーン別に最適なAI導入提案を行います。システム化、業務改善、効率化を得意とし、具体的な活用事例、期待効果、導入ステップを含む実践的な提案を提供します。Use when proposing AI/LLM adoption strategies for specific industries, departments, or business scenarios.

takusaotome/claude-skills-library92026年10月5日 更新

Generate AI-powered BPO service proposals for Japanese companies in the US market. Use when creating outsourcing proposals with AI service menus, ROI estimation, implementation roadmaps, and bilingual (JA/EN) proposal documents for 在米日系企業向けAI実装.

日本語の概要は準備中です。原文の説明を表示しています。

takusaotome/claude-skills-library92026年10月5日 更新

ai-text-humanizer

無料日本語概要

AI(LLM)が生成した日本語テキストの「AI臭」を検出・診断し、人間らしい文章にリライトするスキル。 Use when: 「AIっぽい文章を直して」「人間らしくリライトして」「AI臭を消して」「この文章をもっと自然にして」 「テキストのAI感を減らして」「機械っぽさを取りたい」 "make this sound more human", "remove AI tone", "humanize this text", "detect if this is AI-generated". 6つのAI特有パターン(視覚的マーカー、単調なリズム、マニュアル的構成、非コミット姿勢、抽象語の濫用、 定型メタファー)を正規表現ベースで検出し、0-100のAI臭スコアを算出。3つの人間化技法 (バランスを崩す・客観を崩す・論理を崩す)でリライトを実行する。 Note: 検出スクリプトは日本語テキスト専用。英語テキストの場合はClaude自身がreferences/を参照して分析・リライトする。

takusaotome/claude-skills-library92026年10月5日 更新

Generate audit-ready internal control design documents from As-Is business process inventories. Produces control IDs, assertion mappings, procedures, SoD analysis, KPIs, materiality thresholds, and implementation roadmaps. Use when building internal controls for new audit engagements, SOX/J-SOX compliance, or process improvement initiatives.

日本語の概要は準備中です。原文の説明を表示しています。

takusaotome/claude-skills-library92026年10月5日 更新

Review audit-related documents (control design documents, bottleneck analyses, requirements definitions, etc.) for quality, scoring them 0-100 with a severity-rated findings list. Use when reviewing audit documents, checking control design quality, or verifying cross-document consistency. Supports documents governed by US GAAP, IFRS, or J-GAAP.

日本語の概要は準備中です。原文の説明を表示しています。

takusaotome/claude-skills-library92026年10月5日 更新

takusaotome のスキルをすべて見る

このスキルの問題を報告する