test-driven-development

テスト駆動開発

公開インターフェースを通じて、いくつかの振る舞いテストを使います。このスキルは、ユーザーが TDD／テストファーストを求めた場合、またはリポジトリの指示でこのサイクルが必須の場合にのみ適用します。共通の可読性ルールについてはcodebase-designに従い、テスト範囲についてはwhen-to-write-testsに従います。

使用する場合

• ユーザーが TDD、テストファースト、またはレッド・グリーン・リファクタリングを求めている場合
• 変更に対して、リポジトリの指示で失敗するテストから始めるサイクルが必須の場合

使用しない場合

• TDD の要望や要件がない通常の実装やリファクタリング
• プライベートヘルパーの移動、コメントの編集、またはドキュメントのみの編集
• TDD の要望や要件はないものの、コントラクトテストを求められた場合。そのテストの選択にはwhen-to-write-testsを使用します
• 「新しい関数／メソッドすべて」
• アドバイザーが独自に考案した、コントラクトに含まれない境界条件
• 公開動作が既存のテストでカバーされている場合

デフォルトでは新しいテストを追加しません。変更した経路のスモークテストを実施します。when-to-write-testsを参照してください。

作成するテスト

実際の経路をたどるテストを 1 つ（または少数）作成します。つまり、公開境界での入力からシステムを通り、観測可能な結果に至るまでを検証します。

良い例：既存の受信テーブルにデータを投入し、マイグレーションを適用し、イベントを一覧表示して、事実とメタデータが保持されていることを検証します。

悪い例：ヘルパー、エンコーダー、バインドリストの書き換えごとにテストを作成します。

モックより、実際のコラボレーターを優先します。それらのコントラクトについてはルート／ストア／UI の経路をテストし、公開された純粋関数は入出力を通じてテストします。補足資料：tests.md、mocking.md。

テストの配置場所

ソースの隣に配置します。foo.tsの隣にfoo.test.tsを置きます。これらのテスト用に、パッケージ内にトップレベルのtest/やtests/ディレクトリを別途作成しないでください。

例外：実際のサーバーや CLI を起動するエンドツーエンドテスト、または複数のパッケージにまたがるテストは、リポジトリルートのtests/に配置します（例：tests/smoke.test.ts）。

サイクル（このスキルが適用される場合のみ）

1. 観測可能な動作を 1 文で示します。
2. 公開インターフェースを通じて、失敗するテストを 1 つ作成します。
3. そのテストを通す、最もシンプルで完全な実装を作成します。
4. 理解しやすくなる場合にのみリファクタリングし、関連するロジックはまとめておきます。
5. 次に必要な動作について繰り返します。新しいヘルパーごとにテストを追加しないでください。

コントラクトで必要な場合は、失敗時、完了時、クリーンアップ時の動作も含めます。公開された純粋関数には、アプリケーション全体を対象とする E2E ハーネスは必要ありません。

TDD をやり直すために、動作しているコードを削除しないでください。TDD サイクルが要望または要件でない場合は、リポジトリで定められた、変更規模に応じた検証ポリシーを使用します。

競合

ユーザーの指示とリポジトリの要件を優先します。必須の公開動作やライフサイクルのカバレッジを免除するのではなく、冗長なテストを避けるためにwhen-to-write-testsを使用します。