ユニットテストをしなかった私が得たもの | column

昨年の１２月は子供の風邪について、私の風邪と、歳の瀬を感じる気分になる暇すらなく、目まぐるしい一ヶ月があっという間に過ぎ、お正月からは、家族にインフルエンザー、風邪が続出で、これまた目まぐるしい歳初めとなりました。今年も少しでも皆様にお役に立てるように、頑張って書いて行きますので、宜しくお願いします。

さて、以前は Makefileの改善を放棄したことから始まったこのシリーズですが、ユニットテストを選択しなかった、私は何を得たのだろうか？

ユニットテストを選択していれば、ワンクリックで、モジュールの正常性を確認できます。問題が発生した場合、素早く検出し、それを対応することで簡単にシステムを補強でき、さらなる可能性にチャレンジしていくことができます。。一度奪い取った陣地は、永久に確保され、補強にも簡単にできたはずです。しかも、ユニットテストは我々に従来と違い、軽快な開発をもたらし、仕事の楽しさを実感させられることができます。

しかし、ユニットテストを選択しなかった私は、 Makefileの修正で、２ヶ月の手動全テストを行なうかどうかの選択に迫られてしまう。ごく簡単なはずの修正で、これだけの労力も、コストも許されないだろう。しかし、お恥ずかしいことながら、最近私は、ごく数文字しか違いがない新規の定数と、既存の定数を勘違いコードを作成し、同じパスが通るものが多数ある為ということで、テストを省いてしまったがばかりに、お客さんから障害として挙がってきました。本当に些細な間違いで、お客さんの信頼を損なわれたことは、本当に申し訳なくもあり、悔しくもありました。

システムというのは、大きくなればなる程、我々の了解範囲内だけでは、考慮し切れないものがあります。また、ちょっとした油断で、問題を起こしてしまうのです。人間の脳は、柔軟で、判断力に富んでいるが、コンピュータはそうはいきません。動作して、確認できて初めて、信用できるのです。テストは必須です。我々はしばしば、テスト実施の必要性と、かかるコストとの狭間に立たされ、苦しむことがあります。

修正や、変更、バージョンアップがある度に、その手動テストが繰り返されてくるのである。全く同じテストですよ。可笑しくはありません？この状況を人は成功しているという人もいます。多大な犠牲を支払って、陣地を奪い取り、そして、ほたらかしに去ってしていく、ことがある度に、多大な犠牲を支払って、陣地を奪い返す。そして、またほたらかしに去っていく。

P.S. 最近は、第14回XPユーザ会に出席させて頂いて、 IBMの小柳さんと、小林さんの「ペアプロ適用事例」の発表を聞かせて頂くチャンスに恵まれました。質疑応答の際、「ペアプロのデメリットはなかったか」との質問に対して、「最後までデメリットを感じなかったから、最後までやりました。」とのお答えにはいたく勇気付けられました。ますくさんとのXP実践は、とかく理論を現状に合わせて実行方法に変換していくことの繰り返しでした。全てを自分たちのやり易い形に変えていったので、あまりデメリットを感じたことなく、「デメリットは？」と聞かれ、答えに窮することが多くありました。現状に合わせていたので、理論と差異が多いのではとも思っていました。他の方にもその良さを分かって頂けたことは誠に喜ばしい限りです。

私は今でも、既存システムへの部分的なユニットテストを導入し、既存コードをリファクタリングし、システムを改良し、より強固なものにしていくことを夢見ております。行なえるように努力しておりますが、既に２度程失敗しております。未だ実力不足ということもあり、ますくさんとXP実践では、既存システムへの導入事例が少なく、自力での実現には至っておりません。また、既存システムの多くは、つながりが密で、テスト可能になるように設計されていませんので、部分的に、既存コードへのユニットテストをかけることは困難であると感じております。また周りの人のほとんどは、目の前の仕事だけに目が行ってしまう人が多く、プロセスの改良に意識がいかないのが現状です。極めて残念ではありますが、今後とも、「問題が見えれば、自分が答えの最もそばにいる」との信念に基づいて、どんどん仮説→検証→フィードバックというサイクルを繰り返して、問題解決に臨んでいきたいと思います。

フィードバック下さい！

There is no comment.

Chat (Lingr.com)

Informaiton

Daily

Column

Zope Solution

Extra

アーカイブ

OSS案内所

Site Info

関連リンク

フィードバック下さい！