リグレッションテストに感謝します。 今週の初め、私は自分が書いた（と思っていた）新しいコードのいくつかをデバッグして、とても良い気分になっていました。 私は今、バイナリ時間値を分解された時間構造（Cの専門家の皆さんには「構造体tm」）に変換するOpenVOSのPOSIX関数を強化しているところです。 1998年に戻って、私が元々POSIX環境で動作するようにこれらのルーチンを修正したとき、私は近道をして、基礎となるVOSカーネルのサブルーチンを呼び出しました。 このアプローチは速くてシンプルでしたが、VOSは1970年から1980年の日付を扱わないので、POSIXランタイムは1970年から1980年の日付を扱うことができませんでした。 最近、私はいくつかの主要な新しいオープンソースパッケージをOpenVOS 17.0に移植してきました。 この範囲の日付を扱えないために、多くのテストに失敗していることがわかりました。そこで、私はVOSとUNIXの両方の時代(1970年から2048年まで)のすべての日付を扱えるようにコードを修正する作業に取りかかりました。 この作業がエラーを起こしやすいことはわかっていましたが、私はコードからすべてのバグを取り除く方法を見つけようと決心しました。 日付を扱うことの良い点の一つは、集合が有限であるということです。 さらに、最近のコンピュータは非常に高速なので、可能なすべての組み合わせをクランチして、何が起こるかを確認するのはそれほど難しいことではありません。 ここでは触れませんが、1970年と1971年を扱うコードの領域を確実にテストしたかったのです。そこで、1970年1月1日から現在まで、1日に2回変換するテストを書きました。 それはCPU時間のほんの数分の1秒しか使いませんでした。 案の定、私のコードにフェンスポストのエラーを見つけました。 私はそのエラーを修正し、テストは合格しました。 このプロセスについてはかなり良い感じで、監査人が変更を承認してくれたので、これで終わりだと思っていました。 その後、私の同僚が私の変更に対してリグレッションテストスイートを実行しました。 コンパイラとそのランタイムに変更を加えるたびに、誤って何かを壊していないことを確認するために、この作業を行います。 私にとっては残念なことに、いくつかのリグレッションテストが失敗しました。 私のテストでは、明らかに徹底したテストを行っているにもかかわらず、なぜそれが検出されなかったのかを発見したとき、問題は2038年まで発生していなかったことがわかりました。 私は1970年から1980年までの10年間を時間ルーチンに追加していましたが、2038年から2048年までの10年間を切り取っていました。 案の定、その範囲内で毎日テストしてみると、私のテストは問題を捕らえていたことが証明されました。
ここでの教訓は何でしょうか？ 最も明白なのは、すべての組み合わせをテストできるのであれば、実際にすべての組み合わせをテストすることを確認することだと思います。 おそらく、より重要な教訓は、時間をかけてリグレッションテストスイートを構築することです。 リグレッションテストは時間と労力をかける価値があります。 コードを強化する際に、コストを削減し、問題を見つけて修正する時間を短縮することができます。 顧客から報告された多くの問題を避ける必要はなく、回帰テストスイートを作成するためのコストを正当化することができます。 私は、ソフトウェアの問題を修正するためのコストは、プロセスのフェーズが増えるごとに桁違いに高くなると見積もっています。 どのプロセスにも少なくとも4つのフェーズ(設計、コード、テスト、デプロイ)があるので、すぐに高くなってしまいます。