TL;DR
- テストを後から書くと、実装中にフィードバックが得られず、エッジケースのバグも見つけにくい。
- TDD の本質はテストファーストではなく「迅速な反復」であり、それがコーディング体験そのものを変える。
内容
テストを後から書くことの欠点
この章のテーマは、Jest によるテスト駆動開発である。「テストを後から書く」アプローチには、次の 3 つの欠点がある。
- 機能を実装している間にフィードバックを受け取れない。
- 実装後に書いたテストは、想定どおりに動くことを確かめるだけになりやすい。そのため、エッジケースで起きるバグを見つけられない。
- 既存のコードの構造を見直さずに機能を足そうとする。他の機能を壊すかもしれないという不安から、リファクタリングを避けがちになる。
これらの欠点は、TDD の重要な要素である「テストを先に書く」（テストファースト）ことで避けられる。
TDD の本質は迅速な反復
ただし、テストファーストは TDD で重要ではあるが、本質ではない。TDD の本質は「迅速な反復」であり、次の流れを繰り返す。
- 小さなテストを 1 つ書く。
- そのテストが失敗することを確かめる。
- テストをパスするだけの実装を書く。
- テストがパスすることを確かめる。
- Git で進捗を保存する。
TDD はコードカバレッジを上げるだけでなく、コーディング体験を変える。テストが先にあれば、何がうまくいき何がうまくいかないかというフィードバックをすぐに確認できる。そのおかげで、さまざまなアプローチを試せるし、クリーンなコードにするためのリファクタリングもできる。この「実験」が学びにつながり、より良いコードを生む。
キーワード
自分の理解
テスト「駆動開発」という名前のとおり、テストは品質を確かめる道具であると同時に、開発を前に進める原動力でもある。