| name | add-tests |
| description | git diff origin/main... の差分を分析し、変更されたメソッド・関数に対する不足テストを追加・修正する。ファイル拡張子を引数で指定する（例: /add-tests .rb）。テストの追加、テストカバレッジの補完、変更に伴う既存テストの修正が必要な場面で使う。TRIGGER when: ユーザーが変更に対するテスト追加、テストギャップの補完、差分やブランチのテストカバレッジ確認、壊れたテストの修正を求めたとき。'テスト書いて'、'テスト足りてない'、'テスト追加して'、'add tests'、'write tests for my changes' などのフレーズにも反応する。 |
Add Tests
ブランチの変更差分を分析し、不足しているユニットテストを追加・修正するスキル。
引数
ファイル拡張子を引数として受け取る（例: /add-tests .rb、/add-tests .ts）。
拡張子は . 付きで指定する。複数指定はスペース区切り（例: /add-tests .rb .ts）。
ワークフロー
Step 1: 差分の取得と分析
git diff origin/main... を実行して変更内容を取得する- 指定された拡張子のファイルのみを抽出する（テストファイルは除外）
- 変更されたメソッド・関数を特定する:
- 新規追加されたメソッド/関数
- ロジックやシグネチャが変更されたメソッド/関数
- 削除されたメソッド/関数（関連テストの削除・修正が必要）
差分が大きい場合は、ファイルごとに段階的に分析する。一度に全体を把握しようとせず、1ファイルずつ読んで理解を積み上げる。
Step 2: 既存テストの調査
変更されたファイルそれぞれについて:
- 対応するテストファイルを探す。見つからない場合は、プロジェクト内のテストディレクトリ構造と命名規則から適切なパスを推測する
- テストフレームワークを特定する:
- ディレクトリ構造（
spec/, test/, __tests__/, *_test.go など）
- インポート文やフレームワーク固有の記法
- 既存テストのスタイルを把握する。これに合わせて書くことで、プロジェクト内の一貫性を保つ:
- テストの構造化パターン（
describe/it, Test*, def test_* など）
- セットアップ/ティアダウンの方法
- モック・スタブの使い方
- アサーションのスタイル
Step 3: テストギャップの特定
変更されたメソッド/関数ごとに:
- 既存テストの有無を確認
- テストがある場合: 変更内容を反映できているか、カバレッジが足りているか分析
- テストがない場合: 新規テストが必要とマーク
Step 4: テストの追加・修正
確認は不要。リポジトリ配下のファイルは自由に読み書きしてよい。ギャップ分析が終わったらそのままテストを書く:
新規テスト追加:
- 正常系（基本的な動作確認）
- 境界値・エッジケース（空入力、nil/null、上限値など）
- エラーケース（不正な入力、例外発生パターン）
既存テスト修正:
- シグネチャ変更への追従
- 期待値の更新
- モック・スタブの更新
テストファイルの配置・命名は既存の規約に厳密に従う。新しい規約を持ち込まない。
Step 5: テストの実行と確認
テストを書いたら実行して結果を確認する。失敗がある場合は原因を調べて修正する。テストのロジック自体が間違っている場合は修正し、プロダクションコードのバグを発見した場合はユーザーに報告する（勝手に直さない）。
重要な原則
- 既存スタイルに合わせる: プロジェクトのテストの書き方を尊重する。自分の好みを押し付けない。
- スコープを絞る: 変更されたメソッド/関数のテストだけを書く。関連するが変更されていないコードのテストは書かない。
- 純粋関数・ビジネスロジック優先: UIテストやE2Eテストは対象外。
- 型安全性:
any 型や過度にゆるい型は使わない。
- 明確なテスト名: 何をテストしているか一目でわかる名前をつける。
