特集 「テスト駆動開発」はプログラマのストレスを軽減するか？ 株式会社ピーデー 川俣　晶 2003/11/08
Page1 Page2 Page3 Page4

プログラマに優しいTDD

　さて、以上の手順を見て、レッド／グリーン／リファクタリングのリズムが、小さく繰り返されていることが分かるだろう。サイクルの短さは、TDDの1つの特徴といえる。しかし、それがいったい何をもたらしてくれるのだろうか。

　まずグリーン状態が長期間続き、レッドはほんの短い時間しか現れないことに注目しよう。もし、サイクルを大きく取って回すと、グリーン状態が長続きできないケースが生じる。例えば、100個のテストを作成し、それをパスする100個のメソッドを作成するなら、100個目のメソッドが完成するまで、グリーンバーを見ることができない。しかし、TDDはサイクルが小さいので、ほとんどの時間はグリーンの状態が維持され、一時的に、1つの項目だけがレッドに陥るだけである。それも、短時間でグリーンに回復する。テストが失敗している状態が放置されるよりも、いつもテストをパスしている方が、プログラマにとって気分が良いだろう。気分が良ければ生産性が上がるかもしれない。プログラミングとは、精神状態で生産性が変わる（と筆者は考えている）、とてもメンタルな作業なのである。その点で、TDDはプログラマに優しいという特徴をもって、生産性を向上させる効能を持つといえるかもしれない。

　さらに、意図しない状況でテストをパスしないケースが出てきた場合、常にグリーンを維持しながら作業する場合と、多数のレッド項目を抱えながら作業する場合では、解決のための労力が違ってくる。前者の場合、ちょっと前にソース・コードを戻せばグリーンになるので、その段階から後に行われた修正の中に問題があるのは明らかである。しかし、レッド項目が多い場合、それらのどれかが悪影響を及ぼして、パスすべきテストを失敗させた可能性がある。その場合、問題を含むかもしれないコードの範囲は広く、そう簡単に原因を特定できない可能性もある。そのような状況を考えても、常にグリーンを維持し続けることは、手間を減らすプログラマに優しいやり方といえるのではないだろうか。

　もう1つ、グリーンとリファクタリングが、手順として分離されている点も、心理的な負担の軽減に役立っているといえるだろう。テストをパスさせる、というのは心理的な負担のかかる作業だが、きれいなコードを書くということも、同様に心理的な負担のかかる作業である。特に、どんなコードを書けばテストをパスするか分からず試行錯誤しているときに、きれいなコードについて注意を払う余裕などないかもしれない。だが、TDDは、パスするためのコードを得るための段階と、きれいなコードを書くための段階を分離したので、負担が分散され、無理がかからない。それに加えて、この2つを分離することは、コードが予想外の形で記述完了してしまった場合にも効力を発揮する。最初の予想に沿ってきれいなコードになるように苦労したのに、実際には予想外の形になって、苦労が無に帰すこともあるだろう。だが、まず動かすことに注力し、動いてからコードをきれいにするなら、動かないコードをきれいにする労力は必要とされない。

　さて、筆者が感じるTDDの最大の良さは、短いサイクルがつくり出すリズム感である。前掲の『テスト駆動開発入門』では、15〜30分というサイクルが書かれているが、場合によっては、それより短い時間でサイクルが回る場合もある。1つのサイクルが回ると、一仕事終えた、という気持ちになる。これは、心地よいものである。これが、数時間のうちに何度もやってくるのである。これはとても気持ちが良い。この気持ちの良さは、さらなるやる気を引き出し、前向きなフィードバックをもたらす。

どんなときに、TDDを採用すべきか

　TDDはどんなときに採用すべきだろうか。基本的には、大抵のプログラムは、TDDを採用して改善を期待できる余地があると思ってよいだろう。また、試みることができる状況は、かなり幅広いだろう。冒頭で述べたように、TDDを採用していないプロジェクトのメンバーが、1人でTDDを試みることも不可能ではない。例えば、テストを書き、本来作成すべきコードを書き、リファクタリングしてからテストコード抜きでプログラムを納める、というやり方は可能だろう。せっかく作成したテストを納める時点で捨てることになり、少々もったいないという感じはあるし、テストが取り除かれるとそれ以後のリファクタリングも円滑にできなくなる。そういう問題はあるにせよ、小さな範囲で試すことができないわけではない。小さなチャレンジに優しい、という点もTDDの特徴といえるだろう。

　では、どんなときにTDDを採用すべきではないか。筆者の個人的な感想ということをあらかじめ断っておくが、恐らくオブジェクト指向のモデリングを重視して行うプロジェクトは、TDDと相性が悪いだろう。というのは、TDDではコードの重複を取り除き、リファクタリングを行っていく過程で、クラスが生まれたり消えたりするからだ。例えば、『テスト駆動開発入門』に出てくる例でも、クラスが生まれたり消えたりする過程が描かれている。もし、個々のクラスが存在することに必然性があり、個々のクラスが特定の役割を担うことが期待されるなら、コードの重複を取り除く、というような目的のために、クラスが生まれたり消えたりすることは受け入れられるものではないだろう。このような問題は、オブジェクト指向モデリングという技法を支持しない筆者のようなプログラマであればまったく問題はないが、もっぱらオブジェクト指向モデリングを通してプログラムの構造をイメージする「オブジェクト脳」の持ち主には厳しい制約かもしれない。

■コラム：小さなサイクルを円滑に回すためのTODOリスト

　本文にうまく収まらなかったTDDの特徴に、TODOリストの活用がある。TODOリストというのは、やるべきことを書き留めておくメモとなる文書である。電子的に用意しても、紙に書いてもどちらでも構わないと思う。専用のソフトを使っても、テキスト・エディタで書き留めても問題ないだろう。Visual Studio .NETにもビルドインされたTODOリスト機能があるので、それを使うことも可能だろうし、そうではない方法を使ってもよい。ちなみに筆者は、いまのところテキスト・エディタである「秀丸」でTODOリストを記録しているが、より便利さを求めてほかの方法に移行するかもしれない。

　さて、なぜTODOリストなのだろうか。TDDは小さいサイクルを回していくので、必然的に、行うべき作業の数（サイクルの数）が増える。例えば、「今週の君の仕事は巨大で高機能な顧客管理クラスを作ることだ」と命じられた場合、1サイクルは1週間ということになるので、作業すべき項目をリストアップして管理することもないだろう。覚えるべき項目は1つだけだからだ。しかし、15〜30分でサイクルを回していくとすれば、項目の数はグッと増える。それを忘れないように適切に管理するにはTODOリストが必要というわけである。

　もう1つ忘れてならないのは、思い付いた作業項目をすぐに追加できる機能性である。例えば、あるメソッドを作成中に、別のメソッドでテストしていない条件があることに気付いたとしよう。そのような場合には、作業を中断してテストを追加するのではなく、テストを追加すべきことをTODOリストに書き加えておくのである。これにより、レッド状態を一時放置して、別のレッド状態をつくり出すようなシチュエーションを回避できるし、優先順位が低い作業項目なら、ずっと後の時間まで作業を引き延ばすこともできる。しかし、リストにしっかり書き込んでおけば、忘れ去ることはない。

　このように、TODOリストは、TDDにはとても重要な役割を持つツールなのである。

INDEX
	［特集］「テスト駆動開発」はプログラマのストレスを軽減するか？
	1．新しいソフトウェア開発技法へチャレンジできるか？
	2．レッド／グリーン／リファクタリングの三拍子
	3．再びレッドとグリーン、そしてリファクタリング
	4．どんなときにテスト駆動開発を採用すべきか

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）