tdd:write-tests

ローカルの変更をテストでカバーする

ユーザー引数

ユーザーは、対象とするテストやモジュールを指定できます。

$ARGUMENTS

何も指定されていない場合は、現在の git diff に含まれる未コミットの変更をすべて対象にします。すべてコミット済みの場合は、最新のコミットを対象にします。

コンテキスト

新機能の実装や既存コードのリファクタリングを行った後は、ビジネスロジックの変更がすべてテストでカバーされていることを確認することが重要です。このコマンドでは、カバレッジ分析と専門エージェントを使用して、ローカルの変更に対するテスト作成を自動で進めます。

目標

ローカルコードの変更に含まれる重要なビジネスロジックを、包括的にテストでカバーします。

重要な制約

• 重要なビジネスロジックに注力する — すべての行を 100% カバーする必要はありません
• 既存のテストを維持する — 新しいテストだけを追加し、既存のテストは変更しないでください
• 「変更の複雑さを分析する」 —
  • 変更されたファイルが 2 つ以上ある場合、または 1 つのファイルに複雑なロジックが含まれる場合は、自分でテストを書かず、エージェントのオーケストレーションだけを行ってください。
  • 変更されたファイルが 1 つだけで、変更が単純な場合は、自分でテストを書いてもかまいません。

ワークフローの手順

準備

1. 利用可能であれば sadd スキルを読む

   • 利用可能な場合は、エージェントを管理する際のベストプラクティスを把握するため、sadd スキルを読んでください。

2. テスト基盤を確認する

   • @README.md と package.json（または同等のプロジェクト設定ファイル）を読みます。
   • テストとカバレッジレポートを実行するコマンドを特定します。
   • プロジェクトの構成とテストの規約を把握します。

3. すべてのテストを実行する

   • 全テストスイートを実行して、ベースラインを確認します。

分析

haiku エージェントを使って、手順 4〜5 を並行して実行します。

4. 個別のテスト実行を確認する

   • 成功するテストファイルを任意に 1 つ選びます。
   • haiku エージェントを起動し、このテストファイルだけを実行する適切なコマンドを見つけるよう指示します。
     • 個別のテストを確実に実行できるまで、試行を繰り返すよう依頼します。
   • エージェントの作業が完了したら、テストファイルが存在する場合は、そのファイルを指定して実行してみます。
   • これにより、エージェントがテストを個別に実行できることを確認します。

5. ローカルの変更を分析する

   • git status -u を実行し、未追跡ファイルを含む変更ファイルをすべて特定します。
     • 未コミットの変更がない場合は、最新のコミットで変更されたファイルの一覧を取得するために git show --name-status を実行します。
   • ドキュメントや設定ファイルなど、コード以外のファイルを除外します。
   • 変更された各ファイルに対して個別に haikue エージェントを起動し、ファイルの内容と変更の複雑さを分析して、短い要約を作成するよう指示します。
   • 実際にロジックが変更されたファイルの一覧を抽出します。

テストの作成

単純な単一ファイルのフロー

変更されたファイルが 1 つだけで、変更が単純な場合は、自分でテストを書いてもかまいません。次のガイドラインに従ってください。

1. テスト作成のベストプラクティスを把握するため、TDD スキルを読みます。
2. 対象ファイル {FILE_PATH} を読み、ロジックを理解します。
3. 既存のテストファイルを確認して、パターンとスタイルを把握します。存在しない場合は作成します。
4. 変更をカバーするために追加すべきテストケースを分析します。
5. 特定したすべてのケースについて、包括的なテストを作成します。
6. 前に特定したテストコマンドを実行します。
7. すべてのテストが成功するまで、問題を修正して繰り返します。

テストは次の条件を満たすようにしてください。

• 明確で保守しやすい
• プロジェクトの規約に従っている
• 実装ではなく動作をテストする
• エッジケースとエラー経路をカバーする

複数ファイルまたは複雑なファイルフロー

変更されたファイルが複数ある場合、または1つのファイルに複雑なロジックがある場合は、変更内容を網羅するために専用のエージェントを使用する必要があります。次のガイドラインに従ってください。

6. code-review:test-coverage-reviewer エージェントを起動する（並列）（Sonnet または Opus モデル）

   • 変更されたファイルごとに、カバレッジレビュアーエージェントを1つ起動します
   • 各エージェントに次の情報を提供します。
     • コンテキスト：このファイルの変更内容（git diff）
     • 対象：分析する特定のファイル
     • リソース：README と関連ドキュメントを読むこと
     • 目標：追加が必要なテストスイートを特定すること
     • 出力：重要なビジネスロジックに必要なテストケースの一覧
   • すべてのカバレッジレビュー報告を収集します

7. テストファイル用に developer エージェントを起動する（並列）（Sonnet または Opus モデル）

   • テストが必要な変更ファイルごとに、開発者エージェントを1つ起動します
   • 各エージェントに次の情報を提供します。
     • コンテキスト：このファイルのカバレッジレビュー報告
     • 対象：テストを作成する特定のファイル
     • テストケース：カバレッジレビュアーエージェントからの一覧
     • ガイダンス：テスト作成のベストプラクティスについて、利用可能であれば TDD スキルを読むこと。
     • リソース：README とテスト例を読むこと
     • コマンド：このファイルのテスト実行方法
     • 目標：特定されたすべてのケースについて包括的なテストを作成すること
     • 制約：既存のロジックは変更せず、新しいテストを追加すること（明らかに壊れている場合を除く）

8. カバレッジを検証する（反復）（Sonnet または Opus モデル）

   • ファイルごとに code-review:test-coverage-reviewer エージェントを再度起動します
   • 次の情報を提供します。
     • コンテキスト：元の変更と追加した新しいテスト
     • 目標：重要なビジネスロジックがすべて網羅されていることを検証すること
     • 出力：確認結果、または不足しているカバレッジの一覧

9. 必要に応じて反復する

• カバレッジがまだ不足しているファイルがある場合：手順5に戻ります
• 不足があるファイルに限り、新しい開発者エージェントを起動します
• まだ不足している点について具体的な指示を提供します
• 重要なビジネスロジックがすべて網羅されるまで続けます

10. 最終検証

• テストスイート全体を実行し、すべてのテストが成功することを確認します
• 利用可能であれば、カバレッジレポートを生成します
• 既存のテストにリグレッションがないことを確認します

成功基準

• 変更されたファイル内の重要なビジネスロジックがすべてテストで網羅されている ✅
• 新規および既存のすべてのテストが成功する ✅
• テスト品質がカバレッジレビュアーエージェントによって検証されている ✅

エージェント指示テンプレート

カバレッジレビューエージェント（初期分析）

Analyze the file {FILE_PATH} for test coverage needs.

Context: This file was modified in local changes:
{GIT_DIFF_OUTPUT}

Your task:
1. Read the changed file and understand the business logic
2. Identify all critical code paths that need testing:
   - New functions/methods added
   - Modified business logic
   - Edge cases and error handling
   - Integration points
3. Review existing tests (if any) to avoid duplication
4. Create a list of test cases needed, prioritized by importance:
   - CRITICAL: Core business logic, data mutations
   - IMPORTANT: Error handling, validations
   - NICE_TO_HAVE: Edge cases, performance

Output format:
- List of test cases with descriptions
- Priority level for each
- Suggested test file location

開発者エージェント（テスト作成）

Create tests for file {FILE_PATH} based on coverage analysis.

Coverage review identified these test cases:
{TEST_CASES_LIST}

Your task:
1. Read TDD skill (if available) for best practices on writing tests
2. Read @README.md for project context and testing conventions
3. Read the target file {FILE_PATH} and understand the logic
4. Review existing test files for patterns and style
5. Create comprehensive tests for all identified cases
6. Run the tests: {TEST_COMMAND}
7. Iterate until all tests pass
8. Ensure tests are:
   - Clear and maintainable
   - Follow project conventions
   - Test behavior, not implementation
   - Cover edge cases and error paths

Test command: {TEST_COMMAND}

カバレッジレビューエージェント（検証）

Verify test coverage for file {FILE_PATH}.

Context: Tests were added to cover local changes in this file.

Your task:
1. Read the changed file {FILE_PATH}
2. Read the new test file(s) created
3. Verify all critical business logic is covered:
   - All new functions have tests
   - All modified logic has tests
   - Edge cases are tested
   - Error handling is tested
4. Identify any gaps in coverage
5. Confirm test quality (clear, maintainable, follows TDD principles)

Output:
- PASS: All critical business logic is covered ✅
- GAPS: List specific missing test cases that need to be added