tdd

テスト駆動開発

TDD とは red → green のループである。このスキルは、そのループが「残す価値のあるテスト」を生み出すためのリファレンスだ：良いテストとは何か、テストはどこに置くか、アンチパターン、そしてループのルール。すべてのセクションが毎サイクルに適用される — ループの前と最中に参照すること。後からではない。

コードベースを探索するときは、プロジェクトのドキュメント（CLAUDE.md や docs/ 配下の設計メモなど、あれば）を読み、テスト名やインターフェースの語彙がプロジェクトのドメイン用語と一致するようにすること。

良いテストとは何か

テストは、実装の詳細ではなく、公開インターフェースを通じて振る舞いを検証する。コードが丸ごと書き換わっても、テストは変わらないべきだ。良いテストは仕様書のように読める —「有効なカートを持つユーザーはチェックアウトできる」は、どんな能力が存在するかを正確に伝える — そして内部構造に無関心だからこそリファクタリングを生き延びる。

例は tests.md を、モックの指針は mocking.md を参照。

継ぎ目（seam）— テストを置く場所

**継ぎ目（seam）**とは、テストを当てる公開境界のこと：内部に手を突っ込まずに振る舞いを観察できるインターフェースだ。テストは継ぎ目に置く。内部に対しては決して書かない。

事前に合意した継ぎ目でのみテストする。 テストを 1 つでも書く前に、テスト対象の継ぎ目を書き出してユーザーと確認すること。未確認の継ぎ目にテストを書いてはいけない。すべてはテストできない — 継ぎ目を先に合意することで、テストの労力があらゆる端ケースではなく、クリティカルパスと複雑なロジックに集中する。

問うべきこと：「公開インターフェースは何で、どの継ぎ目をテストすべきか？」

アンチパターン

• 実装結合 — 内部のコラボレーターをモックする、プライベートメソッドをテストする、あるいは横道から検証する（インターフェースを使わずデータベースを直接クエリするなど）。見分け方：振る舞いが変わっていないのにリファクタリングでテストが壊れる。
• トートロジー — アサーションが期待値をコードと同じやり方で再計算している（expect(add(a, b)).toBe(a + b)、同じ手順で手作りしたスナップショット、定数を自分自身と比較する等）。構造上必ず通ってしまい、コードと食い違うことができない。期待値は独立した真実の源から来なければならない — 既知の正しいリテラル、手計算した例、仕様書。
• 水平スライス — テストを全部先に書き、それから実装を全部書く。まとめて書いたテストは_想像上の_振る舞いを検証している：ユーザーに見える振る舞いではなく物事の_形_をテストしてしまい、テストは現実の変化に鈍感になり、実装を理解する前にテスト構造にコミットしてしまう。代わりに垂直スライスで進めること — テスト 1 つ → 実装 1 つ → 繰り返し。各テストは、直前のサイクルで学んだことに応答する**曳光弾（tracer bullet）**である。

ループのルール

• 緑の前に赤。 まず失敗するテストを書き、それを通すのに必要なだけのコードを書く。将来のテストを先取りしたり、投機的な機能を足したりしない。
• 一度に 1 スライス。 1 サイクルにつき、1 つの継ぎ目、1 つのテスト、1 つの最小実装。
• リファクタリングはループの一部ではない。 それはレビュー段階（/code-review スキル参照）に属するもので、red → green の実装サイクルには含めない。