tdd

テスト駆動開発

一度に1つの振る舞いテストを通じて実装を進めます。テストを先に書くワークフローを使わずにテストの必要性や品質を判断する場合は、代わりに test-judgment.md をお読みください。

前提条件

依頼または承認済みの計画に示されたパブリックインターフェースと対象の振る舞いを使用します。判断に必要な情報が不足していて、意味のあるテストを書けない場合に限り質問してください。決着済みの選択肢を再確認しないでください。

新しいテストを書く前に、テストの必要性の判定基準を使って、検出するリグレッションを明確にし、重複するカバレッジがないか確認してください。テストが不要と判断された場合は、RED を作り出さずにそのスライスを完了し、免除について報告してください。ファイルのカテゴリだけを理由に免除することはできません。

レッド・グリーン・リファクタリング

1. 観測可能な振る舞いを対象に、焦点を絞ったテストを1つ書きます。外側から内側へ進めます。最初のテストは、その環境で振る舞いを確認できるレベル、つまり統合テスト、CLI テスト、またはエンドツーエンドテストにします。実装上必要になった場合に限り、より小さなテストを続けて追加します。テストを実行し、無関係なコンパイルエラーやセットアップ失敗ではなく、想定した理由で RED になることを確認します。
2. GREEN にするために必要な最小限の本番コード変更を行い、テストを実行します。
3. GREEN の状態を保ったままリファクタリングし、影響を受けるテストを再実行します。承認済みの対象をカバーするまで、次の振る舞いについて繰り返します。

テストが別のテスト作成者によって用意された場合、実装者はそれを前提として扱います。テストの編集や弱体化はせず、誤りがあると考える場合は、その理由とともに作成者またはユーザーに差し戻します。

テストをすべて先に書き、その後で実装をすべて行うことは避けてください。垂直スライスを用いることで、各テストを想像上の実装ではなく、直前のサイクルで明らかになった内容に基づかせることができます。

RED に入る前に、読み取りやベースライン確認を行ってもかまいません。振る舞いを変更する本番コードの編集は、RED より前に行ってはいけません。新たなスコープ、設計、安全性に関する判断が生じない限り、サイクルの合間にユーザーの承認を求めて中断しないでください。

スライスに必要なものだけを読む

• tests.md：テストの品質が不確かな場合の具体例。
• mocking.md：分離する境界の選び方。
• refactoring.md：テストに合格する実装のリファクタリング。
• verification-placement.md：型チェッカー、ジェネレーター、互換性チェック、またはテストのどれが懸念事項を担当するか。

完了条件

対象となるすべての振る舞いについて、パブリックインターフェースを通じたテストに合格し、本番実装前に各テストが想定した理由で RED になり、影響を受けるテストが GREEN であること。検証が妨げられている場合や、未カバーの振る舞いが残っている場合は、完了と主張せずに報告してください。免除したスライスは、test judgment に従って、懸念事項を担当する仕組み、または担当する仕組みが明示的に存在しないことを記録します。