File contents テスト駆動開発(TDD)
Red-Green-Refactorサイクルに基づくテスト駆動開発を支援します。
TDDサイクル
フェーズ
説明
実施内容
Red
失敗するテストを書く
要件を満たすテストケースを作成し、実行して失敗を確認
Green
テストを通す最小限のコード
テストが通る最小限の実装を追加
Refactor
コードを改善
重複排除、可読性向上、設計改善を実施
TDD原則
テストファースト : 実装前に必ずテストを書く
最小実装 : テストを通す最小限のコードのみを書く
リファクタリング : グリーンになった後、コード品質を改善
小さなステップ : 一度に1つの機能に集中
継続的な実行 : テストを頻繁に実行し、即座にフィードバック
開発手順
1. Red(失敗するテストを書く)
テストファイルの扱い :
コード開発 : 作成したテストファイルは最終成果物として残す(例: tests/*.bats)
ドキュメント開発 : 検証用のテストチェックリスト(TEST.md など)は、Greenフェーズ完了後に以下のいずれかを実施
不要な場合は削除する
継続的な品質確認が必要な場合は残す
実装ガイドとして有用な場合は本体ドキュメントに統合する
2. Green(テストを通す)
3. Refactor(リファクタリング)
3.1. コード改善
コードの重複を排除
命名を改善
設計パターンの適用
パフォーマンス最適化
3.2. ローカルテスト実行
3.3. ローカルLint/Format実行
Lintチェックを実行して警告がないことを確認
# Shell Script Linting
docker compose run shell-dev lint-shell
Lintで問題がある場合には、コードフォーマットを適用する、個別に修正するなどして対応する
# Shell Script Formatting (check)
docker compose run shell-dev shfmt -d -i 2 .
# Shell Script Formatting (apply)
docker compose run shell-dev shfmt -i 2 -w .
GitHub Actionsワークフローを修正した場合はActionLintを実行
# GitHub Actions Linting
docker compose run shell-dev actionlint
3.4. Git Commit & Push
3.5. Pull Request 作成
3.6. CI確認
Pull Request作成後、GitHubでCI/CDパイプラインが自動実行される
以下のチェックが全て成功していることを確認:
Actionlint : GitHub Actions ワークフローファイルの構文チェック
ShellCheck + shfmt : シェルスクリプトの静的解析とフォーマットチェック
Test : プロジェクト固有のテスト実行
CIが失敗した場合:
PRページでログを確認してエラー原因を特定
ローカルで同じコマンドを実行して再現
修正後、コミット・プッシュしてCIが再実行されるのを確認
テスト品質チェックポイント
項目
チェック内容
カバレッジ
重要なパス、エッジケース、エラーケースを網羅
独立性
テスト間の依存関係がない
明確性
テストの意図が明確で可読性が高い
速度
テストが高速に実行できる
信頼性
テストが安定して同じ結果を返す
出力形式
Red フェーズ
実装する機能の要件説明
作成したテストコード
テスト実行結果(失敗の確認)
Green フェーズ
実装したコード
テスト実行結果(成功の確認)
実装の説明
Refactor フェーズ
リファクタリング内容の説明
改善後のコード
ローカルテスト実行結果(引き続き成功の確認)
ローカルLint/Formatチェック結果(全て通過)
Git Commit & Push の実行
Pull Request 作成
CI結果の確認(PR作成後に自動実行、全てのチェックが成功)
改善のポイント
GitHub Actions CI
プロジェクトでは以下のCI/CDチェックが自動実行されます:
Actionlint : GitHub Actions ワークフローファイルの構文チェック (actionlint.yml)
ShellCheck + shfmt : シェルスクリプトの静的解析とフォーマットチェック (ci.yml)
Test : プロジェクト固有のテスト実行 (ci.yml)
CI/CDパイプラインのURL: https://github.com/{owner}/{repo}/actions
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1 --- 2 name: yellow-seed-agentusagewidget-test-driven-development 3 description: テスト駆動開発(TDD) 4 --- 5 6 # テスト駆動開発(TDD) 7 8 Red-Green-Refactorサイクルに基づくテスト駆動開発を支援します。 9 10 ## TDDサイクル 11 12 | フェーズ | 説明 | 実施内容 | 13 | -------- | -------------------------- | ---------------------------------------------------- | 14 | Red | 失敗するテストを書く | 要件を満たすテストケースを作成し、実行して失敗を確認 | 15 | Green | テストを通す最小限のコード | テストが通る最小限の実装を追加 | 16 | Refactor | コードを改善 | 重複排除、可読性向上、設計改善を実施 | 17 18 ## TDD原則 19 20 1. **テストファースト**: 実装前に必ずテストを書く 21 2. **最小実装**: テストを通す最小限のコードのみを書く 22 3. **リファクタリング**: グリーンになった後、コード品質を改善 23 4. **小さなステップ**: 一度に1つの機能に集中 24 5. **継続的な実行**: テストを頻繁に実行し、即座にフィードバック 25 26 ## 開発手順 27 28 ### 1. Red(失敗するテストを書く) 29 30 - 要件を理解し、期待する振る舞いを定義 31 - テストケースを作成(エッジケース、境界値も考慮) 32 - テストを実行して失敗を確認 33 34 ```bash 35 # プロジェクト固有のテストコマンドを実行 36 37 # Shell Script Testing (bats) 38 docker compose run shell-dev bats tests/ 39 40 # 特定のテストファイルのみ実行 41 docker compose run shell-dev bats tests/example.bats 42 ``` 43 44 - 失敗理由が意図通りであることを確認 45 46 **テストファイルの扱い**: 47 48 - **コード開発**: 作成したテストファイルは最終成果物として残す(例: tests/\*.bats) 49 - **ドキュメント開発**: 検証用のテストチェックリスト(TEST.md など)は、Greenフェーズ完了後に以下のいずれかを実施 50 - 不要な場合は削除する 51 - 継続的な品質確認が必要な場合は残す 52 - 実装ガイドとして有用な場合は本体ドキュメントに統合する 53 54 ### 2. Green(テストを通す) 55 56 - テストを通す最小限のコードを実装 57 - ハードコードや単純な実装でも可 58 - テストが全て通ることを確認 59 60 ```bash 61 # Shell Script Testing (bats) 62 docker compose run shell-dev bats tests/ 63 ``` 64 65 - 新しいテストで既存テストが壊れていないか確認 66 67 ### 3. Refactor(リファクタリング) 68 69 #### 3.1. コード改善 70 71 - コードの重複を排除 72 - 命名を改善 73 - 設計パターンの適用 74 - パフォーマンス最適化 75 76 #### 3.2. ローカルテスト実行 77 78 - テストが全て通り続けることを確認 79 80 ```bash 81 # Shell Script Testing (bats) 82 docker compose run shell-dev bats tests/ 83 ``` 84 85 #### 3.3. ローカルLint/Format実行 86 87 - Lintチェックを実行して警告がないことを確認 88 89 ```bash 90 # Shell Script Linting 91 docker compose run shell-dev lint-shell 92 ``` 93 94 - Lintで問題がある場合には、コードフォーマットを適用する、個別に修正するなどして対応する 95 96 ```bash 97 # Shell Script Formatting (check) 98 docker compose run shell-dev shfmt -d -i 2 . 99 100 # Shell Script Formatting (apply) 101 docker compose run shell-dev shfmt -i 2 -w . 102 ``` 103 104 - GitHub Actionsワークフローを修正した場合はActionLintを実行 105 106 ```bash 107 # GitHub Actions Linting 108 docker compose run shell-dev actionlint 109 ``` 110 111 #### 3.4. Git Commit & Push 112 113 - すべてのローカルチェックが通ったら、変更をコミット・プッシュ 114 115 ```bash 116 git add . 117 git commit -m "type: description" 118 git push 119 ``` 120 121 #### 3.5. Pull Request 作成 122 123 - Pull Requestを作成(詳細は [.claude/skills/pull-request/SKILL.md](../pull-request/SKILL.md) を参照) 124 125 ```bash 126 gh pr create --title "type: description" --body "..." 127 ``` 128 129 #### 3.6. CI確認 130 131 - Pull Request作成後、GitHubでCI/CDパイプラインが自動実行される 132 - 以下のチェックが全て成功していることを確認: 133 - **Actionlint**: GitHub Actions ワークフローファイルの構文チェック 134 - **ShellCheck + shfmt**: シェルスクリプトの静的解析とフォーマットチェック 135 - **Test**: プロジェクト固有のテスト実行 136 - CIが失敗した場合: 137 1. PRページでログを確認してエラー原因を特定 138 2. ローカルで同じコマンドを実行して再現 139 3. 修正後、コミット・プッシュしてCIが再実行されるのを確認 140 141 ## テスト品質チェックポイント 142 143 | 項目 | チェック内容 | 144 | ---------- | -------------------------------------------- | 145 | カバレッジ | 重要なパス、エッジケース、エラーケースを網羅 | 146 | 独立性 | テスト間の依存関係がない | 147 | 明確性 | テストの意図が明確で可読性が高い | 148 | 速度 | テストが高速に実行できる | 149 | 信頼性 | テストが安定して同じ結果を返す | 150 151 ## 出力形式 152 153 ### Red フェーズ 154 155 - 実装する機能の要件説明 156 - 作成したテストコード 157 - テスト実行結果(失敗の確認) 158 159 ### Green フェーズ 160 161 - 実装したコード 162 - テスト実行結果(成功の確認) 163 - 実装の説明 164 165 ### Refactor フェーズ 166 167 - リファクタリング内容の説明 168 - 改善後のコード 169 - ローカルテスト実行結果(引き続き成功の確認) 170 - ローカルLint/Formatチェック結果(全て通過) 171 - Git Commit & Push の実行 172 - Pull Request 作成 173 - CI結果の確認(PR作成後に自動実行、全てのチェックが成功) 174 - 改善のポイント 175 176 ## GitHub Actions CI 177 178 プロジェクトでは以下のCI/CDチェックが自動実行されます: 179 180 - **Actionlint**: GitHub Actions ワークフローファイルの構文チェック ([actionlint.yml](.github/workflows/actionlint.yml)) 181 - **ShellCheck + shfmt**: シェルスクリプトの静的解析とフォーマットチェック ([ci.yml](.github/workflows/ci.yml)) 182 - **Test**: プロジェクト固有のテスト実行 ([ci.yml](.github/workflows/ci.yml)) 183 184 CI/CDパイプラインのURL: `https://github.com/{owner}/{repo}/actions` 185 186 --- 187 > Converted and distributed by [TomeVault](https://tomevault.io/claim/yellow-seed) — claim your Tome and manage your conversions. 188 <!-- tomevault:4.0:skill_md:2026-04-13 -->
tomevault-io/skills-registry/tree/main/yellow-seed--agentusagewidget--test-driven-development commit b504f1c59a
Frequently asked questions How do I install the Yellow Seed Agentusagewidget Test Driven Development skill? Run npx skillmds@latest add tomevault-io/yellow-seed-agentusagewidget-test-driven-development in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
What does the Yellow Seed Agentusagewidget Test Driven Development skill do? テスト駆動開発(TDD) It is listed under Coding & Dev Tools on SkillMD.
Is Yellow Seed Agentusagewidget Test Driven Development safe to use? This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
Which AI agents work with Yellow Seed Agentusagewidget Test Driven Development? This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Is Yellow Seed Agentusagewidget Test Driven Development free to use? Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
Who published Yellow Seed Agentusagewidget Test Driven Development? tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.