「テスト駆動開発」の版間の差分

*できる限り早く、テストがパスすに通るような最小限のコード本体を書く

**Fake Itの後に、次の段階（リファクタリングの段階）へ進めないようなず漠然としている場合は、さらに別のデータを用いたテストを追加し、その2つのテストの共通点を見出して助けとする（Triangulate；[[三角測量]]）。

*テストが通ることを確保しつつ、コードそれ自体やコードとテストの間にある明示的・暗黙的な重複を取り除く（リファクタリング）。通常、リファクタリングとは、コードの意味を変えずにコードを再構築することをいう。なお、この「コードの意味」とは、テストが通ることを言う。また、リファクタリングここで取り除く重複には、形式的なもの重複だけでなく、意味的なもの重複も含まれる。例えば、Fake Itでハードコーディングしたものは、おおよそ実際にはどこからか得られるはずのパラメータを、別の値を用いて算出したものであるため、これを重複と見なす。そして、重複を取り除くことで、ロジックが抽出される。

テストコードは、最初から自明であるとは限らない。むしろ、コード本体と同様、最初は具象的なテスト（例えば、単なるフラグの確認）を行い、これによって知見を得た後に、テストを書き直したほうがよい。また、テストコードから導かれるコード本体は、リファクタリングの過程によって、あるいはテストが成熟するに従って、最終的な目的とするコード本体のテスト用スタブに変わっていくかもしれない。早い段階でテストとコード本体を分離して管理するのはあまり意味がない。テストやコード本体が成熟していくにつれ、テストの記述が抽象的・間接的になり、リスクが導入される（例えば、フィールドを直接参照する代わりにgetterメソッドを使うなど）。しかし、テスト駆動開発のテストの目的は、開発者の正しさへの確信を裏づけするためであり、それが保たれているならば問題はない。