Tyzoh.jp

職業プログラマの間では、単体テスト（ユニットテスト）の自動化はさほど進んでいないことを知っているので、わざと挑発的なタイトルにしてみました。

え？まだ自動化してないの？

というニュアンスです。

テストは自動で流れるけどテスト結果は人間が一生懸命分析して正しいかどうかわかる、というのではダメです。すべてのテストに通ったかどうかが見て１秒でわかる仕組みのことです。画面に「成功」か「失敗」かのどちらかが出ればよい。

単体テストの自動化というと、JUnit（あるいはホゲホゲUnit）などのツールとXP（やアジャイル）などの開発プロセスなどとセットで語られることが多いと思います。しかし、私はツールや開発プロセスにかかわらず単体テストの自動化はできるし、すべきだと思っています。

ウォーターフォール型でもいいから、テストファーストじゃなくてもいいから、ツールだってなんでもいいから、とにかく単体テストの自動化はやるべきです。あえて断言すると、単体テスト自動化は常にベストプラクティスになると思っています。

もし例外があるとすれば、テスト作成が間に合わないほど頻繁な仕様変更がある場合でしょうね。しかし、これは開発手法以前の問題があることが多いでしょう。

以前、某大規模開発プロジェクトで単体テスト自動化を提案してうまくいったこともあり、常日頃から私はそう思っていました。しかし、最近さらに確信するような出来事が２つありました。

・「達人プログラマー」を読んだ
・Apacheのソースコードを読みながらモジュールを開発した

「そんなこといったって自動化なんかできるはずないじゃないか！」
「自動化したってメリットなんてあまりないんじゃないか？」
「あなたの言っていることはわかる。でもうちのプロジェクトは自動化できない。」
という人は、まず「達人プログラマー」を読んでみてください。「達人〜」というタイトルですが、初心者にもわかりやすい本だと思います。上記の反論への反論は、一通りこの本に書かれています。

Apacheについては、ソースコードに単体テストコードが含まれているのでかなり救われました（オープンソースでは普通のことですが）。Apacheに入っている関数を利用しようと思うのだがその使い方がわからない、しかもドキュメントもない、ということが最近多いです。そうすると当然ソースを読むのですが、そのときに役立つのがテストコードです。テストコードには、このライブラリはこう呼び出したらこういう結果が返ってくるはずという「意図」が書かれているので、仕様がよくわかる。

会社のプロジェクトでプログラミングしていたときは、ライブラリの仕様書を読んでもよく理解できず、結局開発者にメールや電話で問い合わせるということがよくありました。Apacheまわりで開発していると、そういう必要性はあまり感じないですね。

こういう文化があるから、オープンソースのコミュニティは発達できるんでしょうね。職業プログラマも見習うべきところがたくさんあるように思います。