Bobおじさんが述べるTDDの適用可能性

作者 Mike Bria , 翻訳者 竹中 翔 - (株)ポータルアイランド 投稿日 2009年11月17日

セクション

プロセス/プラクティス,

デベロップメント,

設計/アーキテクチャ

トピック

Agile ,

アジャイル技術 ,

Ruby ,

プログラミング ,

.NET ,

Java

タグ

テスト ,

TDD

原文(投稿日：2009/11/04)へのリンク

"TDDによってペースが鈍ると考えている人は石器時代で生きつづけているようなものだ"と主張したことで議論を巻き起こしたブログに続き、Bob Martin氏は現実のTDDの適用可能性、役割、恩恵に対する深い洞察を試みている。

氏はまず"TDDはアーキテクテャの代替物か？"という大きな問題を取り上げ、実例を背景に「そうではないですが、しかし...」と答えている。

いちから始めて次々にテストケースを書いていくことで実行可能なアーキテクチャを生成できるという意見は全くばかげたことです。テストしないという決断を下す必要もあります。

もちろんこれらの決断の多くはできるだけ先延ばしにすることができるし、そうすべきです。例えば、データベーススキーマは恐らく長い時間待つことが可能なものです。Spring、JSF、Hibernate、JPAなどを使うかどうかの決断もたぶん待つことができます。ビジネスルールの美しさはデータベースやGUIモデルとは独立して実装することができるし、またそうすべきです。
...
ここが肝心なところです。TDDで完全なアーキテクチャを導き出すことはできません。TDDはアーキテクチャ上の決断にいくらかの情報を提供することはできますが、アーキテクチャビジョンなしにプロジェクトを始めることはできません。だから、前もっていくつかのアーキテクチャは必要です。アーキテクチャのアクティビティの中で最も重要なもののひとつはアーキテクチャ要素が先延ばしにできるのか否かを決めることです。

アーキテクチャの疑問に答えた後、Martin氏は次の話題"TDDは設計の代替物か？"に挑んでいる。この疑問に対する回答のエッセンスはこのようなものだ。

答えはノーです。設計スキルは必要です。設計原則やデザインパターンについての知識はやはり必要です。UMLについて知っているべきです。そして、ソフトウェア設計の軽量モデルを作るべきです。
...
肝心なのはTDDが設計テクニックのひとつであり、唯一のものであるべきではないということです。古い設計ルールやスキルは今でも生かすことができます。そしてTDDはそれらに情報を与え、増補するためのパワフルな方法です。

Martin氏の"石器時代"ブログの発言に戻ってみると、氏は"コードの全ての行にTDDを使うべきか"という疑問に結論を下している。再度、答えは"ノー"だと述べている。

使うべきではありません。TDDが有効ではないものがあります。GUIはその一例です。
...
もちろん、GUIだけではありません。キーはいじるという概念です。コードを伝達しなければならない場合、顧客の要求のためにいくつかの側面をいじる必要がある場合、編集と実行の迅速なサイクルによって解決できるとはっきりしない場合、TDDは恐らく助けになるよりも邪魔になります。
...
これを管理するための秘訣は強力な分離です。いじる必要がないコードを識別し、TDDを使って書けるモジュール内にコードを分離し、いじられたコードは隔離されておりかつ最小限であるようにしてください。

いくつかのテストは後で書いた方がよいという事実を認め、Martin氏は必要な時（"いじる"ことが必要とされた時）にだけすべきかについて再度取り組んでいる。氏はテストが初めに書かれていない場合、ほとんどの訓練されたプログラマでさえある程度のテスト困難なコードを書かなければならなくなるということを説明し、"全ての行、全ての決断がテストされるチャンスを大きく広げる"という、この背景にある第一の理由を述べている。

そして、Bobおじさんは"テストの必要性を受け入れるなら、なぜテストファーストに反対するのか"という面白い問題を提示している。このため、氏はコードが徐々に増えていくと考えることができない人がいる、という仮説を立てている。

正直なところ、なぜテストファーストに対してこのような強い抵抗があるのか私はわかりません。どのみち我々はテストを書くつもりなので、明らかにそれは生産性の問題ではありません。

たぶん、テストを最初に書くことがフローの中に割り込んでくることを望まない人々がいるのです。それは正しく、テストを最初に書いている時、アルゴリズム全体を書くことはできません。１つずつテストケースを追加しながら、少しずつアルゴリズムを組み立てなければなりません。もしかすると、この方法を心地よい作業だと感じない人々がいるのかもしれません。

Martin氏は最後に「高いテストカバレッジを気にかけずに早く先に進めばいいのでは？」というよくある意見に答えている。氏はまずレガシー環境（コードがテストを持たない環境）で高いカバレッジを得ることはコストが高く、長期の投資を要求すると認めている。だが非レガシー環境やレガシー環境の新しいコードに対しては、氏の答えは異なるものである。このようなケースでは、高い自動テストのカバレッジは作業を迅速化してくれる。なぜなら

第一に、大量のデバッグが不要になります。実際にコードの全ての行をテストしたらどうでしょうか？私自身の経験で言えば、デバッグ時間はほとんど消えてなくなります。昨年のFitNesseの開発で私はデバッグにほとんど時間を使いませんでした。時間にして５時間かそれ以下でした。

第二に、不注意でコードをこわしてしまうことがありません。テストスィートは数秒でこのような破損箇所を見つけ出します！これは私を怖いもの知らずにしてくれます。怖いもの知らずであれば、ずっと早くできるようになります。

第三に、テストはシステムがどのように動くかの例になります。システムのある部分がどうやって動くか忘れた時はいつも、私はテストを読みます。これらによってすぐにスピードを取り戻すことができます。

第四に、私はフィールドからのバグの連発と戦っていません。何千ものユーザーがいるにも関わらず、バグリストは小さなものです。サポートに使った時間は１週間に１時間以下で、大抵はユーザーガイドの正しい場所を教えてあげることだけです。

Bobのブログで詳細とこれらのアイディアの具体例を見ることができる。そして、少し時間をとってコメントのかなりの量のフィードバックとさらなる貴重な投稿も読むべきだ。

• 次へ >