tdd

テスト駆動開発

新しい振る舞いごとに、その振る舞いを実装する前にテストを書き、まず失敗することを確認してください。1つの実装で複数のテストを通す場合は、それらを先に書いてもかまいません。ユーザーが求めた場合、またはレッド・グリーン・リファクタリングを行う場合に限り、テストを1つずつ進めてください。

GLOSSARY.mdを読み、次にdocs/decisions/README.mdを使って、テスト対象の振る舞いに関連する決定事項だけを読み込んでください。コード、仕様、決定事項における契約が決定レベルで食い違う場合は、黙って一方を選ぶのではなく、その食い違いを明らかにしてください。テスト名と公開インターフェースには、現行の用語を使ってください。

振る舞いから始める

implementから作業を引き継ぐ際は、対象となる成果、自動テストで証明すべき受け入れ基準、現在のタスクの制約と承認済みの参照資料、および設計の背景となる仕様が示されます。その成果のみを構築してください。仕様は、後続の成果やブロックされている成果を進める許可にはなりません。単独で呼び出された場合は、ユーザーの依頼から期待される振る舞いを導き出し、バグの場合は報告された誤った振る舞いから導き出してください。

コードを書く前に、成果全体を踏まえて設計してください。以下のいずれの基準や明示された理由にも必要とされないコードは書かないでください。

テスト対象を選ぶ

引き継いだ受け入れ基準はすべてテストしてください。追加のテストには、それが保護する対象を明記してください。対象は、再現したバグ、基準では検証できないロジック上のリスク、または変更が影響する既存の振る舞いです。いずれも挙げられないテストを書いてはいけません。自動テストで証明できない受け入れ基準は、その理由とともに差し戻してください。

境界

境界とは、テストが内部に踏み込まずに振る舞いを観察するための公開境界です。

新たに作る前に、既存の境界を再利用してください。名前が変わる可能性のある実装ヘルパーではなく、安定したユースケースやドメイン概念に対してのみ境界を作ってください。合意済みの振る舞いと既存の公開インターフェースから境界を選び、重要な処理経路と複雑なロジックを優先してください。

技術的な不確実性は、リポジトリ内の根拠をもとに解消してください。期待される振る舞いが依然として不明確な場合、または作業を進めることで合意済みのプロダクト契約が変わる場合に限り、ユーザーに確認してください。

すべてのテストが正しい理由で失敗することを確認する

• 新しい振る舞い：振る舞いの実装前にテストを書いてください。テストを実行できるよう、不足している名前にはスタブを用意し、誤った振る舞いまたは振る舞いの欠落を示すアサーションで失敗することを確認してください。コンパイルエラー、不足しているシンボル、インポートの失敗は、ここでいう失敗ではありません。
• バグ修正：まず再現テストを書き、コードを変更する前に、既存のコードで誤った振る舞いにより失敗することを確認してください。
• 既存の振る舞い：実装を壊すか、修正前のコードで実行し、ガード用テストが失敗することを確認してください。

引き継ぎ用に、期待値と実際の値を含む、観測されたアサーションの失敗出力を保持してください。

失敗するテストの信頼性を保つ

失敗したテストは、実装を変更して通してください。成功させるためにテストを削除、スキップ、または弱めてはいけません。実装に対して実行した後でテストを変更する場合は、そのテストが誤っていたことを示す、承認済みの契約またはユーザーの依頼の該当箇所を示してください。

作業を終える前に、変更が影響するコードを対象とする既存のテストを見つけて実行してください。

良いテスト

内部のリファクタリングでテストが壊れないよう、公開インターフェースを通して振る舞いをテストしてください。テスト対象の機能を明示する、仕様スタイルの名前を使ってください。

外部 API、時間、乱数などのシステム境界でのみモックを使い、モックしたデータベースより実際のテスト用データベースを優先してください。

• 実装に密結合したテストは、内部の協力オブジェクトをモックしたり、プライベートメソッドをテストしたり、サイドチャネルで検証したりします。実装が変わる一方で振る舞いが変わらない場合にも壊れてしまいます。
• 同語反復的なテストは、コードと同じ方法で期待値を導き出したり、コードの実行結果から期待値をコピーしたりするため、必ず成功してしまいます。既知のリテラル値、計算例、仕様など、独立した情報源から期待値を取得してください。

リファクタリングして引き渡す

テストがすべて成功している間に限り、リファクタリングしてください。このスキル自体ではレビューを行いません。完成した差分のレビューは、それを担当するワークフロー、またはユーザーが実施するレビューに委ねます。

引き渡すもの：

• コードの変更点。
• 新しいテストごとに1行で、そのテスト名、対象の基準または理由、失敗時に出力されたアサーションの抜粋。
• 自動テストでは証明できなかった、引き渡す各基準とその理由。