78-テストは夜間と週末に

「プログラマが知るべき97のこと」の78個目のエピソードは、ナイトリービルドに関する話です。近年、ハードウェアのコストは充分に下がりマルチコアが当たり前の時代です。一昔前では考えられないようなスペックのマシンが安価で入手できます。それに伴いビルドやテストにかかる時間も随分と短くなりましたが、それでもローカルマシンでフルビルド・フルテストを行うのは結構なストレスです。それならば、マシンが空いている夜間や休日を利用してテストをしようという事が、このエピソードに書かれています。
自分がナイトリービルドを初めて経験したのは５−６年前のプロジェクトでした。その時は閉鎖空間に缶詰系で、マシンスペックもあまり良くなかった記憶があります。炎上しまくってぺんぺん草も残っていない状況で投入されシステム全部を最初から作り直したというプロジェクトでした。そのプロジェクトでは、元請会社のアーキテクトが古いマシンを調達し、夜間ビルド用のマシンを作っていました。夜間になるとナイトリービルドが走り、大量のデータベースアクセス関連のテストを行っていたのです。そのプロジェクトではテスト時間が１日を超えてしまう、いわゆるスローテスト問題も経験しました。途中で調達してきたマシンが余りにもボロく、マシンが起動しなくなったという壮絶なオチがありますが、色々と学ぶ事の多かったプロジェクトです*1。このプロジェクトでは、あいている時間とマシンを利用してテストしていたわけです。
最近はビルド・ユニットテスト専用のサーバを設置することがごく自然に行われています。それほどマシンの価格が下がり、継続的ビルドの有効性が認知されてきているという事でしょう。以前は継続的ビルドを行うためにサーバのセットアップや準備が必要でしたが、今ではJenkinsCI（Hudoson）がありますので導入も簡単です。ユニットテストの実行はほとんどサーバに任せてしまい、問題があればすぐに通知するシステムが安価に構築できるのです。やらないならば、怠慢としか思えません。
継続ビルドが専用サーバで実施するのが自然になると、わざわざ自分のマシンの空いているリソースを夜間や週末に使ってテストする価値はあまりないように思えます。ですが、言い換えれば、より大きな負荷がかかるテストを実施できるとも言えます。例えば、データベースに関連するテストをスローテスト問題を回避するために、モックなどを使って行っていたとします。それは有効なプラクティスですが、モックはあくまでモックです。データベース層以外のテストであってもデータベースを使って本番に近い形でテストできるのであれば、より有用な効果があるとも言えます*2。ですから、あえてフルデータベースで夜間にテストするのもありでしょう。マシンが安価になった今、テストサーバが１台である必要もありません。分散ビルド・テストを行うことも簡単にできます。クラウドを利用すれば夜間だけリソースを借りてテストするという運用もありでしょう。
ナイトリービルド等を行うには特別な環境は必要ありません。ちょっと工夫をするだけで、夜間に小人さんが仕事をしてくれるのです。これは、現代ソフトウェア開発の３本目の柱「自動化」であることは言うまでもありません。

プログラマが知るべき97のこと

*1:新しいマシンは調達できなかった

*2:モジュール間の結合度を下げる目的で分離したいかもしれません