Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

11章テスト概観

Adam Bender 著

Tom Manshreck 編

　テストは常にプログラミングの一部分であり続けてきた。実際、あなたがコンピューターのプログラムを初めて書いたときは、ほぼ確実に、そのプログラムが期待通りに動くかどうかを知るために、何らかのサンプルデータをそのプログラムに投入したことだろう。それと非常に似通ったプロセスが長い間、最先端のソフトウェアテストとして通用していたが、その大部分が手作業で間違いが起こりやすかった。しかし2000年代初頭以降、ソフトウェア業界のテストへのアプローチは、現代のソフトウェアシステムの規模と複雑性に対応するべく劇的な進化を遂げてきた。その進化の中核に位置してきたのが、開発者主導の、自動化されたテストのプラクティスである。

　自動テストにより、バグが野に放たれてユーザーに影響を及ぼすことを防げる。バグは、捕捉するのが開発サイクルの後の方になればなるほど、コストが高くつくようになる。そして多くの場合、コストの増加は指数関数的である†1。しかし、「バグを捕捉すること」は、テストの動機の一部にすぎない。ソフトウェアのテストを望む理由として同等に重要なものは、変化を可能とする能力を備えておくため、という理由である。新機能追加、コードの健全性に主眼を置いたリファクタリングの実施、比較的大規模な再設計への着手と、どれを行っていようが、自動テストは間違いを素早く捕捉でき、そのおかげで信頼性を保ちつつソフトウェアを変更できるようになる。

†1　“Defect Prevention: Reducing Costs and Enhancing Quality”（https://oreil.ly/27R87）を参照のこと。