信頼性のあるテストアプリやテストデータを用意できないと、十中八九モジュールは爆発する――私の職業プログラマとしての経歴の大半は、モジュールの開発に費やされてきたのだが、その中で悟ったことだ。
振り返ると、何らかのアプリケーションなりシステムなりを丸ごと自分で担当した、という機会は少ない。それよりも、そこそこ大きなシステムの一部を開発した、という経験の方が圧倒的に多い。今もそうである。
だからクラスやコンポーネントなど――便宜上、以降ではモジュールと表現する――を実装して、他人に使用してもらったり、時には自身で組み込み先システムにモジュールを呼び出すコードを追加したりする、というスタイルが身についている。
ところで、コーディングしたモジュールは、それ単体では動作しない。動かすためには、組み込み先となる何かを用意しなくてはならない。
開発中のアプリにべったりのモジュールなら、恐る恐るアプリに組み込んで動かすし、独立性の高いモジュールなら、別途テスト用のアプリケーションを用意することになる。
この時、ままありがちなことだが、「信頼性が担保されていないモジュール」を「信頼性に乏しいソフトウェア」に組み込んで動かした場合、何か問題があった時に「モジュール」と「組み込み先のソフトウェア」のどちらに問題があるのか、もしくは双方に問題があるのか、原因の切り分けで苦労することになる。
だから、もしもテスト用のアプリケーションを別途用意することが許される環境であるならば、テストアプリの実装の際には、モジュールを書いた時と同等ぐらいに品質に気を配るべきだ。
もちろん、テストアプリだからこその手抜きは許されるだろう。ただしこの場合の「手抜き」には、「テストアプリの基本的な品質は担保されている」という前提がある。この前提を忘れてはならない。つまり、手抜きが許される部分と許されない部分がある、ということだ。
一般には、テストアプリ実装時に手抜きが許されるのはフールプルーフだろう。利用者が開発者本人ないし同等レベルのプログラマであることもあり、フールプルーフの機構を組み込まずに「運用でカバー」というやり方をしても許される余地がある。
また「無くても困らないが、あれば便利」という機能も、「実装のコスト」と「テスト省力化の期待値」との兼ね合いで省略されることが多い。例えばユーザが入力したパラメータの保存／読み出し機能などは、テストの省力化が期待されるなら実装されるが、それほど省力化に繋がらないなら見送られるだろう。
コードを書けば書くほど、潜在的なバグの数は増えるだろう。その観点では、テストアプリの機能をスリム化することは、テストアプリ自身の品質向上に結びつくはずだ。この点より「無くても困らないが、あれば便利」な機能の実装は見送られやすい、という面もある。
一方で内部品質に関しては、例えテストアプリであっても高品質が求められる。これこそが「テストアプリの基本的な品質は担保されている」という前提をもたらす。仮に内部品質が悪ければ、テストアプリは安定動作せず、モジュール組み込み後に「動作が不安定である原因はモジュールにあるのか、それともテストアプリなのか？」と悩むことになるだろう。
テストアプリに関して言えば、ベテランの言う「手抜きアプリだから」は「内部品質には気を使っているけど、フールプルーフとか便利機能とかはあまり考えていないから」という意味となる。そこだけは、次世代にしっかり伝えておくべきだ。さもなくば後進は内部品質まで怪しいテストアプリを書いてしまうだろう。
