
2006/4/26
■テスト駆動開発(TDD)とは
テスト駆動開発は一般にエクストリーム・プログラミング(XP)の1プラクティスとして紹介されることが多いと思います。しかし、テスト駆動開発自体は決してXPの開発手法に特化したものではなく、さまざまな開発手法とともに有効利用が可能なものです。
では、テスト駆動開発とはいったいどのようなものでしょうか? XPのプラクティスのテスト・ファーストという形で紹介されているときには、次のように説明されていると思います。
- テストツールのxUnitを使う
- コードの中身(実装)を書く前に先にテストコードを書き、その実行結果が失敗(レッドサイン)することを確認しておく
- 実装を書き、テストコードが成功(グリーンサイン)することを確認する
- その後、必要に応じてリファクタリングを行うときに、そのテストコードを使ってテストが成功することを確認する
XPではかなり厳密に手順が既定されていますが、それにはそれなりの理由があるはずです。手順を厳密に定めていることにこめられた意味(あるいは本質)といい換えてもいいかもしれません。ではテスト駆動開発の意味、本質とは何でしょうか?
この大問題を考えるために、まずはもう少し小さな問題について考えてみましょう。クラスやメソッドについてです。テスト駆動開発では『クラスやメソッドなどの定義を、実際に動くプログラムとして定義』しています。このように定義することで生じるメリットがいくつかあります。
- メリット1. テストコードそのものがドキュメントとなる
- メリット2. 改良(リファクタリング)がしやすくなる
- メリット3. 自然にテストがやりやすいコード、つまりモジュール間の結合度の低い良いプログラムとなる
- - PR -
さらに、プログラムを改良した場合でも仕様を満たしているかどうかを機械的に判断させることができるようになります。テストのことを最初から考えてプログラムを書くようになるため、テストがしやすい形で設計するようになります。テストをやりやすくするためにはモジュール間の結合度を低くしなければならず、その結果、自然に良いプログラムとなるメリットがあるのです。
私的な意見としては、必ずしもXPのようにプログラムコードを書く前にテストコードを書くことを強制する必要はないと考えています。なぜドキュメントを残さなければならないかというと、それは時・場所を超えて自分や他人に考えや仕様を伝えるためです。設計という行為と、それをドキュメントに落とすという行為は別物です。 開発形態にもよりますが、少人数であればドキュメントとしてのテストコードを実装コードと同時に作ったり、ちょっとだけ後で作ったりも「あり」でしょう。逆に大人数ならば、実装前のテストコードを、他人に仕様を伝達するための有用なドキュメントとして活用できるかもしれません。それぞれがやりやすいようにやればよいのではないでしょうか。 |
そもそもプログラムの仕様が言葉だけで書いてある状態って、不安じゃありませんか? そのような状態では実際に人間がテストを実施しないと、プログラムが仕様どおりになっているかどうかなんて、誰も保証できないのです。
例えば、ちょっとプログラムを修正した場合でも、関連するすべての部分についての再テストが必要となるはずなのですが、本当に毎回ちゃんと再テストが実施できているでしょうか? 再テストを省いてリリースしてしまった結果、トラブルが発生してしまった、なんてことはないでしょうか? テスト駆動開発では、テストが仕様であり、テストを通すことが必須になるので、仕様を満たさないプログラムがリリースされることはなくなります。プログラムの動作が保証される仕組みになっているわけです。
どうですか? テスト駆動開発を導入しないままでいることのリスクがちょっとは見えてきたのではないでしょうか? ここでさらにテスト駆動開発導入を一押しするために、一歩下がってちょっと周りのことを考えてみましょう。テストの値段を考えてみる、という話です。
| Page1 テストを金額にするといくら? |
|
| Page2 テストの価格って? |
テスト駆動開発で行こう! バックナンバー 連載インデックスへ»
- 第1回 テストを金額にするといくら?
- 第2回 テスト駆動を導入するための3つのポイント
ホワイトペーパー(TechTargetジャパン)
|
|

