Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
うっちーです。
前回は、Makefileの改善について書かせていただきました。 Makefileを改善したが、全画面、全パスをテストすることが必要になり、あきらめました。
今までの我々がやってきたテストを振り返ると、単体テストと、結合テストを中心にやってきたように思います。
単体テストは、ソースを直接呼び出して、if文などの全パスが通るようにテストする。 手動で、時としては、ソースの中にデータを埋め込んで、ソースを動かして動作を確認する。 結合テストは、全画面を一つずつデータを入力して、動かして動作を確認する。 気が遠くなるような膨大な時間をかけて、テスト仕様書を書き、必死にテストをこなしていく。
テストするのではなく、「必死に」テストするのです。 このテストを終えるとき、私達は、ぐったりとして、二度とテストしたくなくなります。 そしてこのテストの間にさまざまなバグが発見され、修正が山ほど出てきます。 ぐったりした後の修正はさらに追い討ちをかけ、疲れが倍増します。
単体テストとは言っても、いくつかの関数が完了しなければ、テストできません。 小心者の私などは、テストできるまで夜も眠れなかったものです。 だって、単体テストしてみたら、自信を持って書いたソースが問題だらけ。。。 自己嫌悪と自信喪失で、疲れが倍々増します。
このテスト後、ソースを改善するときは、全パステストが最善だと言われます。 しかし、とてももう一度テストする気にはなれない。 したがって、「動いたソースは変更するな！」という風潮ができてきます。 どんなにソースが改善できるとしても、書き換えてはいけないのであります。 そして、同じソースがあっちこっちに見かけることになります。 同じ間違いがあっとこっちに見かけることになります。 歯がゆいばかりです。もっとよくできるのに、手をこまねいて見ているしかない．．． ストレスが倍々々増します。
まさしく、中世の騎士のようです。 騎士は、重厚な装備で、防御が完璧なはずなのに、ちょっとした足払いで、倒れたら二度と立ち上がれないのです。 私達は、テストで重厚な装備を、防御が完璧なはずなのに、ちょっとした修正・改善で、その防御がぼろぼろとなるのです。
本当に今までのテストで良いのか？ 毎回毎回同じテストを手動で繰り返すしかないのだろうか？ もっと素早く変更して、素早くテストできないだろうか？ もっと気軽にテストできないのだろうか？
本日も、我々ソフトウェア開発の膨大な人員・時間・資金がテストに投入され、誰も疑問なく、必死にテストしているのだろうか。 人員・時間・資金ばかりが浪費されているわけではありません。 最も重要なのは、人のやる気までもすり減らし、最後には、傷心して人がソフトウェア開発から去っていくことです。 人材喪失こそは、社会の損失であり、ソフトウェア開発が社会に対する背任であります。
There is no comment.