when-to-write-tests について
when-to-write-testsは、コードベースのコントリビューター向けに、テストを追加する条件と方法を示すスキルです。公開インターフェースで観察可能な動作を確認し、変更箇所の実行を重視します。
主な機能
- 01観察可能な公開契約をテスト
- 02動作を確認する小規模なテストを優先
- 03変更経路をスモークチェック
- 04リポジトリのテスト配置ルールに従う
活用シーン
- 01コード変更にテストが必要か判断
- 02再現した公開動作の不具合をカバー
- 03プライベートなヘルパーをテストせず変更を検証
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/when-to-write-testsを入力して読み込まれたか確認します。
詳細
テストを書くタイミング
機能のインターフェースを通じて、観察可能な動作をテストします。共通のルールと例については codebase-design に従ってください。 すべてのプライベートヘルパーにテストを書くより、実際の動作を網羅するテストを少数書くことを優先します。
デフォルト
新しいテストは書きません。
変更した経路のスモークテスト（対象を実行すること）を行います。これが検証になります。
次の場合に限りテストを書く
- ユーザーから依頼された場合、または
- 公開され、観察可能な契約が新設・変更された場合、あるいは再現可能なバグがあり、既存のテストでカバーされていない場合（ストア API、HTTP ルート、マイグレーションのバックフィル、公開計算処理など）。
その契約をインターフェース経由で検証できる、最小限のテストを選びます。 ストアの場合、実用的であれば実際の永続化経路を使います。公開された純粋関数の場合は、入力と出力の動作を直接検証します。失敗、順序、クリーンアップが契約の一部であればテストします。プライベートヘルパーや内部呼び出しに関するアサーションを何層も追加しないでください。
ソースの隣に <file>.test.ts として配置し、別の test/ や tests/ ディレクトリには置きません。実際のサーバーや CLI を起動するテスト、または複数のパッケージをまたぐテストに限り、リポジトリルートの tests/ に配置します。
次のものにはテストを書かない
- コメントやドキュメントのみの編集
- 動作テストですでにカバーされている内部ヘルパー、エンコーダー、バインドリストの書き換え
- 「新しい関数／メソッドすべて」
- アドバイザーが考案した、契約に含まれない境界ケース
- 公開動作が変わらないリファクタリング（既存のテストがリグレッションを検出します）
リポジトリの要件を適用する
現在のユーザー指示とリポジトリの要件は、このスキルより優先されます。テストを追加する前に既存のテストカバレッジを確認してください。必須のリグレッションテストでは、現在の実装を固定するのではなく、観察可能なバグを再現する必要があります。ヘルパーを追加または移動しただけで、TDD を適用しないでください。スモークテストの成功は有用な検証ですが、必須の自動テストの代わりにはなりません。
適切な例
古い受信テーブルにデータを投入し、マイグレーションを適用して、イベントを一覧表示します。事実とメタデータが保持され、matches テーブルが削除されたことを検証します。
不適切な例
ヘルパーごと、またはコメントの書き換えごとにテストを作ること。請求書が保存されたことではなく、saveInvoice がプライベートな insertRow を呼び出したことを検証すること。