はじめて学ぶテスト駆動開発（TDD）

テスト駆動開発（Test-Driven Development）とは、テストファースト、つまり最初にテストを書いてからコードを書く開発手法。日本における TDD の第一人者、@t_wada さんのライブコーディングを見て勉強したのでまとめる。

TDD のゴールは、動作するきれいなコード。「動作するきれいなコード」は、下記の2つに分割できる。

TDD では、先に「動作するコード」を作り、それをリファクタリングによって「きれいなコード」にしていくことで「動作するきれいなコード」にする。TDD は、テストによって動作を保証することによりリファクタリングをやりやすくする手法でもある。

まず、仕様を理解してタスクを分解し、TODO リスト（箇条書き）を作る。

テスト容易性を高くするタスク分解のスキルが必要。最初は難しいが、やってみるとわかってくる。『クリーンアーキテクチャ』などの設計の本を読むのも役立つ。

TODO リストの中から一つを選んで、テストを書く。テストを簡単に書ける（テスト容易性が高い）ものからやるとよい。慣れてくると、テスト容易性とコードの重要度は一致させることができる。

検証 → 実行 → 準備の順番にやるとよい。ゴールから逆算。

TODO リストからテストを書き出せない（リスト内容の抽象度が高すぎる）場合は、TODO リストの抽象度を下げる。

テストを増やすときは、メソッドごと増やす。assert を縦に並べない。理想的には、一つのテストメソッドに一つのアサーション。

仮実装：テストを成功させるための最短距離の実装。きれいなコードでなくて構わない。

三角測量：仮実装から、別の値でも動くようにすること。

明白な実装：一気に実装。

テストコードのテストはプロダクトコードでやる。プロダクトコードに意図的に判別可能な誤りを入れてテストを失敗させるなど。サイクルの1周目は仮実装で OK。

リファクタリングとは、一般的には「外部から見たプログラムのふるまいを変えないで、コードをきれいにすること」。

TDD の考案者 Kent Beckによると、「成功しているテストが成功しているままで、コードをきれいにすること」（コードにはテストコードも含む）。

仕様とコードが頭の中にあるうちに、テストの構造化とリファクタリングまで終わらせる必要がある。

テストコードのリファクタリングは、プロダクトコードのリファクタリングよりは慎重にならざるをえない。リファクタリングも分解することで安全に進められる。

テストにはメンテナンスコストがかかる。テストを増やすのは簡単だが、減らすのはとても難しい。基本的に、テストを書いた本人しかテストを減らすことはできない。メンテナンスコストを下げるためにテストケースは減らしておく必要がある。

テストコードは、動作するドキュメントであるべきだ。テストコードから仕様が読み取れるようにしておかなければならない。テストを書くために抽象度を下げたものは、抽象度が高い（仕様が読み取れる）状態に戻しておく。