「結合テストはでたらめだ」- J.B.Rainsberger氏による連載の紹介

作者 Mike Bria , 翻訳者 金森 諭 投稿日 2009年4月25日

セクション

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

デベロップメント

トピック

Ruby ,

Delivering Quality ,

Java ,

動的言語 ,

品質 ,

言語 ,

.NET ,

ユニットテスト ,

プログラミング ,

Agile ,

TDD ,

テスト ,

Simple Design ,

Productivity ,

Mocks

共有 |

原文(投稿日：2009/4/9)へのリンク

著名なアジャイリストでテスト駆動開発のエキスパートでもあるJ.B.Rainsberger氏（リンク）が始めたブログでの連載では、「結合テストはでたらめだ」という考えさせられる見解になぜ氏が行き着いたかの説明がなされている。

氏はまずパート1（リンク）で「結合テスト」がこの一連の記事において何を意味するかを説明している。

私が結合テストという時、それが何を意味するかを明確にしておくべきでしょう。なぜなら、ソフトウェアのどんな用語でもそうであるように、みなが一致して意味を分かち合うことがないと思うからです。

私は結合テストを、ひとつ以上の振る舞い（細かい些末なものは除きます）の実装の正確さに結果（パスするのであれ失敗するのであれ）が依存するテストの意味として使います。

本当はもっと厳密な定義の方が好みなのですが、この定義でもほとんどのケースで十分足ります。ここで私が重視するシンプルなポイントがあります。それは、さまざまな理由で失敗する可能性のあるテストはごめんだ、ということです。そのようなテストは問題の解決よりも、さらなる問題を生み出します。

次に、なぜプログラマが（あまりに）多くの結合テストをおこなう羽目になるのか、ということの一つの理由をあげている。例となる氏のストーリーでは、プログラマ（あるいはチーム）が結合テストでないとテストができなさそうな欠陥を見つけた時、「結合テスト用のコードが全てきちんと書ければいい」と結論づけて、他の欠陥をもそのままにしてしまっている。

氏はこのように結論づけるのは「まったくひどい考えだ」と半ば自演して立場を明らかにした後、今度はもう少し数字のしっかりしたストーリーとして、結合テストを伴う中規模のウェブアプリケーションのテストへと読者を導く。そこでは数字（「最低1万回のテスト、場合によっては100万回（100万！)のテスト」）を引き合いに出して、そのプロジェクトの時間がどれだけテストを書いたり行ったりすることに費やされているか、またほとんどのチームが結局は徐々に破滅的な方法でテストをするようになってしまう様を述べている。

パート2の「結合テストの隠れたコスト」（リンク）では、「2つのテストスイートの話」という小話によって氏の見解が表されている。この話では、一方のテストスイート（オブジェクトのテストを重視したもののようだ）は実行に6秒かかり、もう一方（統合テストの方により重点があるもののようだ）では1分かかっている。

6秒だけで済むテストスイートの方では、プログラマ（たち）は変更後にテストの「実行」ボタンを押してから結果を得るまでに時間を無駄にすることがない。

6秒で何ができるでしょう？とりあえずテストの実行結果がどうなるか予想するでしょう。全てパスするだろう、書いたばかりの新しいテストが失敗するかもしれない、あるいは10分前にパスしたテストのためにコードをたくさん書いたのだから今度もパスするだろう、と。この程度の時間だと自分で結果を考えることができるのです。そして全てパスしたらリファクタリングをする番だ、と考えることができます。

これとは対照的に、1分かかるテストスイートをおこなうプログラマ（たち）が「実行」ボタンを押すと、次から次へ気を散らさせるフラクタル的な注意散漫世界への旅が始まる。この場合、深刻なコスト上の問題が組み合わさって起きる。

ここで2つのコストを指摘しておかないといけません。まず、私たちがテストを待っている時間＋コンピュータが私たちを待っている時間です。テストランナを60秒間ずっと見ていて、テストが終わり次第すぐに作業を始めるということは、なかなかできるものではありません。しかしそのコストはあまり問題だと思いません。これは目に見ても明らかで測定も簡単なコストです。問題なのは目に見て明らかなのに数値化がほとんど不可能な集中力の損失です。
...
私が（テスト駆動を考慮したオブジェクトの）テストコードを書く時には、当面のゴールを明確にし、それをクリアすることに集中し、それから設計により適した形にまとめることに集中します。これは短いサイクルでおこなわないといけません。それによって集中が持続し、すぐに修復が可能になるのです。この集中と修復のサイクルによってリズムが生まれ、そのリズムによって勢いが生まれます。それがよく言われる「流れ」という協力な状態を生み出すひとつの助けとなります。1分のテストをおこなうと流れを止めてしまいますが、6秒のテスト実行なら流れに戻る勢いを得ることができます。

氏はパート2の結論として、パート1の結びで言及した「テストのうち一番重要なものを○○%をクリアした」ということだけを気にする結合テスト中心の仮説主義プログラマは、「1分間テストスイート」の世界にどんどん追い込まれることになると述べている。

どちらの記事も、ここで手短に要約したものより遙かに詳しいことが書かれていて（記事自体もそうだが、コメントも深い）全部を読む価値があるものだ。そして、このRainsberger氏による興味深い連載はまだ始めの方にすぎないようだ。ぜひとも今後の記事をウォッチして、みなさんの経験を議論に加えてもらいたい。