「なぜ、自動テストを書くのですか？」とか聞かれたので、これはきちんと理解してもらった方がいいなぁ。と思ったので、理由を書いてみる。TDDとかだと設計にもメリットがあるけど、それは今回はおいておく。
１．テストやデバッグに使う時間を削減して、プロダクトコードの品質をあげる
単体・結合・統合テストは全体の8〜25%が費やされるべきであるといわれています。ですが、デバッグは開発の50%におよぶ場合があると言われています。これは、テストには本来多くの時間を割くべきであるが、デバッグが膨大な時間に及ぶことが事実としてあるということです。
 |
スティーブ マコネル￥ 6,405
 |
１．スキルのレベルにかかわらず、プログラマーは全時間のおよそ１０～２０％をコードを書くのにあてており、たいていのプログラマーは完成品ができるまで一日あたりおよそ１０～１２行のコードを書いています。優秀なプログラマーは残りの９０％のうち大部分を、考えること・調べること・最高の設計を見つけるための検証作業に費やします。ダメなプログラマーは残りの９０％のうち大部分を、やみくもに変更と検証を繰り返すようなデバッグ作業に費やします。
チームのメンバーが全員優秀なプログラマーであれば、全く問題ないが、ほとんどのケースはそんなスーパープログラマー達で構成される夢のチームなんてことはない。ここでは、ダメなプログラマーと書かれているが、市場にいる平均的なプログラマーでも闇雲に変更と検証を繰り返してしまうことなんてざらにあるだろう。
問題なのは、チームの規模が大きくなればなるほど、この無駄な時間はどんどんふえていくということ。難解なモジュールつくったヤツが1人いると、プロジェクトスケジュール全体で何度もそれにまつわるデバッグがおこなわれる。今週は自分のチームで。来週は隣のチームで。来月には隣の部署でやってるかもしれない。
もちろん、この難解なモジュールが問題の原因でないケースもある。だが、それをどう証明する？少なくともテストコードを書いていれば、壊れていないことだけは証明できるだろう。
毎週デバッグ大会やってる時間があるならプロダクトコードを書け。それが本来の仕事だ。
２．リファクタリングのサポートをする自動テスト
テストコードはリファクタリングの影響を証明してくれる。上記で示した難解なモジュールをリファクタリングするとしよう。
テストコードが書かれていれば、リファクタリングに挑戦するためのハードルは下がる。難解すぎるから触るのは辞めよう。どうせ壊すから。なんてのは避けられる。
少しリファクタリングをしては、自動テストで確認して、少しずつおこなえば、壊れた箇所もすぐに捕捉できる。確実にリファクタリングすることができる。品質が徐々に上がっていくはずだ。
３．自動テストによって、コードによる修正の影響を即座に得る
自動テストが書かれたプロダクトであれば、あなたがコードを修正して、既存の機能を壊してしまったとしても、自動テストによって、すぐに壊れたことがわかります。そう、リリースするよりも早く、コミットする前にわかるのです。
４．コードによる修正の影響範囲を即座に捕捉する
そして、失敗したテストを確認すれば、コードのどの部分が壊れているのかすぐにわかるでしょう。
闇雲に「どこが壊れているか？」調べるところからスタートではないのです。
５．書くコードの量は増えるが、費やす時間が増えるとは限らない
プロダクトコードに加えて、テストコードを書くのであるからコードの量は増えるはずである。それに費やす時間はふえるだろうが、テストやデバッグに関わる時間は減るはずである。また、プログラマーはテストやデバッグしているよりも、コードを書いてる時間の方が負荷も減り、テストコードは慣れれば相当早く書ける。
苦痛で、ミスや漏れだらけになる、あのデバッグ作業が最小限になるのだ。
自動テストを書いたときにかかる時間（経験による大体の感覚値）
適切なテストケースを書けていれば、通常開発する時間に加えて1.2倍ぐらいの時間で、プロダクトコードとテストコードを仕上げることができるという経験者もいる。目の前のプロダクトコードだけの時間だけかけて、リリースして、バグやデバッグ対応に追われる時間と、そのときに失った損失は、1.2倍の時間では収まらない範囲だと容易に想像できないだろうか？
僕らはバクチをやってるんじゃない。ビジネスをやってるんだ。目を覚ませ!!
 |
ケント ベック￥ 3,150
 |
 |
Christian Johansen、長尾高弘 |
 |
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 David Farley、Jez Humble、和智 右桂、高木 正弘 |
