がんをテストする

私自身のキャリアが、ソフトウェアの開発という日常業務から完全に執筆業へと移り変わったので、日々起こり得るソフトウェアの開発の現実から遠ざかってはいないかと、よく心配になります。現実の感覚を失う著名人を何人も目にしてきたので、自分自身もそうなるかもしれないと恐れているのです。私にとっていちばん抵抗になっているのは、現実の感覚を保つために現実の中を歩いていられるように定期的に情報を提供してくれる Thoughtworks です。

Thoughtworks は、その分野からアイデアを提供する情報源としての役割も果たしており、同僚たちが発見したり開発したりした役立つことを書くことを楽しみにしています。通常、それらのアイデアは役に立つもので、読者のみなさんにも活用していただけるのではないかと期待しています。今日のトピックは、そんな楽しいものではありません。そうではなくて問題なのであって、私たちには答えがありません。

そのシナリオは、こんな具合です。クライアントのためにプロジェクトを実行して、ぴかぴかの最新のソフトウェアを譲渡します。最近の習慣として、そのソフトウェアに必要な自動テストのセットも譲渡します(通常、機能的なコードと同じ行数ほどのテストのコードがあります)。これらのテストは、一般的にユニットテストと、より広範囲におよぶ機能テストと受入テストの組み合わせです。どちらにしても、テストはソフトウェアが何をするかの活発な説明として機能し、ソフトウェアを進化させる際に問題をすばやく見つけ出すバグ検出器としても機能します。私たちはこれらのテストを大切にしています。これらはソフトウェアシステムを構築するうえで成功の鍵です。

数か月後、幸せな顧客がさらにソフトウェアの機能や能力を追加するために連絡をしてきます。私たちがその依頼を受け入れて、欠陥はあるかもしれないが(少なくともそれは) *私たちの* 欠陥であるコードベースに取り組もうとします。そして、不快な事実を発見します。

テストが実行されなくなっているのです。

ビルドスクリプトからテストが除外されて、数か月間まったく実行されていなかったり、場合によっては「テスト」を実行しても、その多くがコメントアウトされていることがあります。どちらにしても、私たちの貴重なテストは、消滅させるのに時間がかかり、イライラさせられるたちの悪いがんで悩まされています。

何が起こったのか尋ねると、「変更を加えたらテストの一部が壊れたので、テストを削除した」といった内容の返答が返ってきたりします。これを *私たち* の失敗とみなすこともできます。顧客のチームに対して、テストの価値について十分に教育できていなかったのです。単に無視するのではなく、失敗したテストを調べる必要があるということを伝えなければなりません。しかし、誰が何を言おうと、テストのがんが一般的な病であることはわかっています。

テストのがんが発生するという事実は、テストを作成しない理由にはならないと考えています。特に猛威を振るう株が納品してから翌日にはテストをすべて消去してしまったとしても、システムを構築していた間は、テストから価値を得ることができました。それに、すべてのテストががんにかかるわけではありません。私たちは最近、数年前納品したシステムの保守を担当した開発者に話を聞きました。この開発者は、テストによって私たちのコードを、後から別会社が追加したコードよりもずっと扱いやすくなったと言っていました。