テストを金額にするといくら？：テスト駆動開発で行こう！（前編）（1/2 ページ）

[五十嵐博, 安中伸彦，株式会社シンプレクス・テクノロジー]

テスト駆動開発（Test Driven Development：TDD）。最近この言葉を聞く機会が多いと思いますが、実際のプロジェクトでTDDを取り入れているというケースはあまり聞きません。本稿は、テスト駆動開発に興味はあるけれど、いまだ導入に踏み切れないという開発者のために、その効用や実際の運用方法について、具体例を交えながら述べたいと思います。前半はテスト駆動開発の意義と、導入に当たっての説得材料について検討します。後半では実際にテスト駆動開発を進めるに当たって具体的にやるべきことについて、事例を踏まえながら説明していきます。

テスト駆動開発（TDD）とは

　テスト駆動開発は一般にエクストリーム・プログラミング（XP）の1プラクティスとして紹介されることが多いと思います。しかし、テスト駆動開発自体は決してXPの開発手法に特化したものではなく、さまざまな開発手法とともに有効利用が可能なものです。

　では、テスト駆動開発とはいったいどのようなものでしょうか？ XPのプラクティスのテスト・ファーストという形で紹介されているときには、次のように説明されていると思います。

1. テストツールのxUnitを使う
2. コードの中身（実装）を書く前に先にテストコードを書き、その実行結果が失敗（レッドサイン）することを確認しておく
3. 実装を書き、テストコードが成功（グリーンサイン）することを確認する
4. その後、必要に応じてリファクタリングを行うときに、そのテストコードを使ってテストが成功することを確認する

　XPではかなり厳密に手順が既定されていますが、それにはそれなりの理由があるはずです。手順を厳密に定めていることにこめられた意味（あるいは本質）といい換えてもいいかもしれません。ではテスト駆動開発の意味、本質とは何でしょうか？

　この大問題を考えるために、まずはもう少し小さな問題について考えてみましょう。クラスやメソッドについてです。テスト駆動開発では『クラスやメソッドなどの定義を、実際に動くプログラムとして定義』しています。このように定義することで生じるメリットがいくつかあります。

• メリット1. テストコードそのものがドキュメントとなる
• メリット2. 改良（リファクタリング）がしやすくなる
• メリット3. 自然にテストがやりやすいコード、つまりモジュール間の結合度の低い良いプログラムとなる

　つまり、言葉でプログラムの仕様を説明する代わりに、テストコードでプログラムの仕様を説明しているわけです。例えば、後からプロジェクトに加わった人でも、テストコードを見ればそのプログラムがどんな動きをするものなのかが分かります。もちろん、使い方も分かります。従来からの開発手法に慣れ親しんでいる人が見たら、詳細設計書を書く代わりにテストコードを書く、といったところでしょうか。

　さらに、プログラムを改良した場合でも仕様を満たしているかどうかを機械的に判断させることができるようになります。テストのことを最初から考えてプログラムを書くようになるため、テストがしやすい形で設計するようになります。テストをやりやすくするためにはモジュール間の結合度を低くしなければならず、その結果、自然に良いプログラムとなるメリットがあるのです。

---

私的な意見としては、必ずしもXPのようにプログラムコードを書く前にテストコードを書くことを強制する必要はないと考えています。なぜドキュメントを残さなければならないかというと、それは時・場所を超えて自分や他人に考えや仕様を伝えるためです。設計という行為と、それをドキュメントに落とすという行為は別物です。

開発形態にもよりますが、少人数であればドキュメントとしてのテストコードを実装コードと同時に作ったり、ちょっとだけ後で作ったりも「あり」でしょう。逆に大人数ならば、実装前のテストコードを、他人に仕様を伝達するための有用なドキュメントとして活用できるかもしれません。それぞれがやりやすいようにやればよいのではないでしょうか。

---

　そもそもプログラムの仕様が言葉だけで書いてある状態って、不安じゃありませんか？ そのような状態では実際に人間がテストを実施しないと、プログラムが仕様どおりになっているかどうかなんて、誰も保証できないのです。

　例えば、ちょっとプログラムを修正した場合でも、関連するすべての部分についての再テストが必要となるはずなのですが、本当に毎回ちゃんと再テストが実施できているでしょうか？ 再テストを省いてリリースしてしまった結果、トラブルが発生してしまった、なんてことはないでしょうか？ テスト駆動開発では、テストが仕様であり、テストを通すことが必須になるので、仕様を満たさないプログラムがリリースされることはなくなります。プログラムの動作が保証される仕組みになっているわけです。

　どうですか？ テスト駆動開発を導入しないままでいることのリスクがちょっとは見えてきたのではないでしょうか？ ここでさらにテスト駆動開発導入を一押しするために、一歩下がってちょっと周りのことを考えてみましょう。テストの値段を考えてみる、という話です。