テスト駆動開発(TDD)とは?

今回は、お客様の開発プロジェクトで何度が質問がありました「テスト駆動開発(test-driven development)」について、解説していきます。

テスト駆動開発(TDD)とは

テスト駆動開発とは、テストファーストなプログラムの開発手法のことです。英語で、Test-Driven Developmentと表記することから、開発者の間では”TDD”と略されます。

テスト駆動開発TDDを採用したプロジェクトでは、プログラムの実装前にテストコードを書き(テストファースト)、そのテストコードに適合するように実装とリファクタリングを進めていく方法を指します。テストを起点とした開発手法である為、実装したい機能のプログラムよりもテストコードを先に書くため、はじめはテストに失敗するのですが、プログラムの実装と修正を短いサイクルで何度も繰り返していくことで不具合・バグをなくしていき、正しく動作するコードが書きあがった時点でリファクタリングを行います。

ウォータフォール型のような開発プロセスでは、設計を行った後にプログラムの実装、そしてテストといった流れで進めていくのですが、テスト駆動開発では、テスト→実装→リファクリングといったテストを起点とした工程を繰り返しながらプロダクトを成長させていきます。その為、この一連の流れを「レッド・グリーン・リファクタリング」と呼ぶことがあります。「レッド・グリーン・リファクタリング」については(もちろんTDDについても)、名著である「『テスト駆動開発入門』 | Kent Beck 著 | 和田 卓人 訳」にその中身の記載がされていますので、気になる方は以下の書籍を読んでみてください。

テスト駆動開発(TDD)のメリット

  • いきなりきれいなコードを書くのは、困難であるという思想のもと、テストとリファクタリングを頼りにコードを整形して作り込んでいく。
  • コードがテスト実行した際に成功する(=Green)であることで、手戻りが発生したかどうかをすぐに確認できる。コードの変更の影響がすぐに可視化できるので、試しながら確認できる。
  • 設計に関する決定のフィードバックをそのままテストコードに記述するので、設計の良し悪しが判断できる。実装に関する決定のフィードバックは、テストの失敗や通過によって通知されるので、設計とテストが近い状態を常にキープでき、採用の決定から短い間隔でフィードバックを得ることができる。
  • テスト駆動開発は、あくまで開発のための手法であり、そこで得られるテストは副産物である。しかし、その開発手順から、コード本体は、テストをパスさせるために記述されたものである。そのため、理想的なテスト駆動であれば、カバレージは100%になる。欠陥やバグは、非常に少ないことが期待される。
  • 必要な仕様は、テストコードでパスすれば良いので、必要最小限の抽象化や複雑さが発生しにくいので、シンプルに保つことができる。

テスト駆動開発(TDD)デメリット

  • 仕様が頻繁に変わるようなタイミングで、テスト駆動開発をするとテストコード作成の頻度が多くなりメンテナンスが大変になります。
  • 開発エンジニアが単体テスト等の経験値をある程度、持っていないと開発時間が膨らみ、開発コストが膨らんでいきます。特にテストコードを書くのに時間がかかるため、開発初期段階での負担が大きくなる傾向があります。
  • 開発手法が変わるので、慣れるまでは、開発工数が増える傾向にあります。
  • UIに近い部分は、頻繁に仕様変更が発生しやすいので、テスト駆動開発の導入による効果を得にくいケースがあります。

テスト駆動開発(TDD)まとめ

テスト駆動開発(TDD)を実際の開発プロジェクトで実践し、確実に成果を出していく為に、ある程度慣れが必要になってくるかもしれませんが、テストコードを書くことでシステムへの理解が深まり、不具合の早期発見、開発者の負担軽減などが実現可能になります。 

システム開発プロジェクトでは、WebやUI等の開発もありますが、いわゆるロジック(ドメイン領域)の開発にテスト駆動開発(TDD)を取り入れることは、比較的取り入れやすいと思いますので、一度、テスト駆動開発 TDDを検討してみてもいいでしょう。

次回は、実際のプロジェクトで行ってるテスト駆動開発の中身についてご紹介してみたいと思います。