教材の内容に関係のない質問や教材とは異なる環境・バージョンで進めている場合のエラーなど、教材に関係しない質問は推奨していないため回答できない場合がございます。
その場合、teratailなどの外部サイトを利用して質問することをおすすめします。教材の誤字脱字や追記・改善の要望は「文章の間違いや改善点の指摘」からお願いします。
2002年にアメリカで出版された「Test-Driven Development By Example」という本の中で、著者の Kent Beck が提唱した開発手法です。
日本では2003年に「テスト駆動開発入門」というタイトルで一度邦訳版が出版されましたが、2013年に絶版になってしまいました。2003年当時は、いまほど自動テストが便利に書けず、コストがベネフィットを上回ると判断されたためか、話題にはなったもののあまり実戦導入にまで至るケースは多くなかった印象です。
その後、2017年に「テスト駆動開発」とタイトルを改めて新訳版が出版され、再びテスト駆動開発ブームが盛り上がっています。それ以前からテスト駆動開発は徐々に浸透し始め、筆者の周りでも導入しているチームが増えました。
本教材では、この新訳版「テスト駆動開発」をベースに、筆者が現場で試行錯誤した経験から有用だと判断したやり方や、チームやプロダクトの状況に合わせてどの辺りでバランスを取ればいいか、といったヒントも提供できればと思っています。
以下の図のように、プロダクションコードを書く前にテストを書き(テストファースト)、テスト失敗 → テスト成功 → リファクタリングのサイクルを細かく回し、徐々に「動作するきれいなコード」を完成させていくスタイルです。
大事なのは、一度で完成させることを目指さず、このサイクルを何度も回して徐々に完成形に近づけていくことです。
テスト駆動開発についての簡潔な説明を「テスト駆動開発」からいくつか引用します。
私たちは、不安を抱えて考え込んでしまうのをやめにして、代わりに自動化されたテストによって開発を推し進める。このような開発スタイルはテスト駆動開発(Test-Driven Development: TDD)と呼ばれる。
- 自動化されたテストが失敗したときのみ、新しいコードを書く。
- 重複を除去する。
テスト駆動開発にはこの2つのシンプルなルールしかない
テスト駆動開発は、プログラミング中の不安をコントロールする手法だ。
TDDはプログラミング中の設計判断とフィードバックの間にあるギャップを認識することであり、そのギャップをコントロールする技法でもある。
Kent Beck. テスト駆動開発. 和田卓人訳. オーム社, 2017
つまり、テスト駆動開発は、テストのための開発技法ではなく、テストコードから書き始めることによって、仕様を明確にしながら、徐々に設計を整えていき、安心して実装できるようにするための開発技法である、といえます。
テスト駆動開発について、ぼんやりとでもイメージできたでしょうか?まだよく分からないという方も安心してください、1章以降で手を動かしながら理解できるよう解説していきますので、徐々に考え方・やり方を身につけていっていただけると思います。