テスト駆動開発(Test Driven Development:TDD)。最近この言葉を聞く機会が多いと思いますが、実際のプロジェクトでTDDを取り入れているというケースはあまり聞きません。本稿は、テスト駆動開発に興味はあるけれど、いまだ導入に踏み切れないという開発者のために、その効用や実際の運用方法について、具体例を交えながら述べたいと思います。前半はテスト駆動開発の意義と、導入に当たっての説得材料について検討します。後半では実際にテスト駆動開発を進めるに当たって具体的にやるべきことについて、事例を踏まえながら説明していきます。
テスト駆動開発は一般にエクストリーム・プログラミング(XP)の1プラクティスとして紹介されることが多いと思います。しかし、テスト駆動開発自体は決してXPの開発手法に特化したものではなく、さまざまな開発手法とともに有効利用が可能なものです。
では、テスト駆動開発とはいったいどのようなものでしょうか? XPのプラクティスのテスト・ファーストという形で紹介されているときには、次のように説明されていると思います。
XPではかなり厳密に手順が既定されていますが、それにはそれなりの理由があるはずです。手順を厳密に定めていることにこめられた意味(あるいは本質)といい換えてもいいかもしれません。ではテスト駆動開発の意味、本質とは何でしょうか?
この大問題を考えるために、まずはもう少し小さな問題について考えてみましょう。クラスやメソッドについてです。テスト駆動開発では『クラスやメソッドなどの定義を、実際に動くプログラムとして定義』しています。このように定義することで生じるメリットがいくつかあります。
つまり、言葉でプログラムの仕様を説明する代わりに、テストコードでプログラムの仕様を説明しているわけです。例えば、後からプロジェクトに加わった人でも、テストコードを見ればそのプログラムがどんな動きをするものなのかが分かります。もちろん、使い方も分かります。従来からの開発手法に慣れ親しんでいる人が見たら、詳細設計書を書く代わりにテストコードを書く、といったところでしょうか。
さらに、プログラムを改良した場合でも仕様を満たしているかどうかを機械的に判断させることができるようになります。テストのことを最初から考えてプログラムを書くようになるため、テストがしやすい形で設計するようになります。テストをやりやすくするためにはモジュール間の結合度を低くしなければならず、その結果、自然に良いプログラムとなるメリットがあるのです。
そもそもプログラムの仕様が言葉だけで書いてある状態って、不安じゃありませんか? そのような状態では実際に人間がテストを実施しないと、プログラムが仕様どおりになっているかどうかなんて、誰も保証できないのです。
例えば、ちょっとプログラムを修正した場合でも、関連するすべての部分についての再テストが必要となるはずなのですが、本当に毎回ちゃんと再テストが実施できているでしょうか? 再テストを省いてリリースしてしまった結果、トラブルが発生してしまった、なんてことはないでしょうか? テスト駆動開発では、テストが仕様であり、テストを通すことが必須になるので、仕様を満たさないプログラムがリリースされることはなくなります。プログラムの動作が保証される仕組みになっているわけです。
どうですか? テスト駆動開発を導入しないままでいることのリスクがちょっとは見えてきたのではないでしょうか? ここでさらにテスト駆動開発導入を一押しするために、一歩下がってちょっと周りのことを考えてみましょう。テストの値段を考えてみる、という話です。
Copyright © ITmedia, Inc. All Rights Reserved.