xUnitなどのテストフレームワークを利用した、テストコードによるテスト(自動テスト)がソフトウェア開発プロジェクトでは一般化しつつある。xUnit導入以前は「テスト仕様書」なるものをまず書いて、レビューをした後に、エンジニアがテスト仕様書を見ながら(手動で)テストを実施していた。単体テストのツールやアプローチが変わったのだから、やり方も見直す必要がある。
自動テストを実施するとなると、全てのレビューを放棄するかのような話を聞きます。
実際、私が自動テストを行ったプロジェクトのいくつかはテストのレビューを行われませんでした。それなのに「自動テストがあるから大丈夫」とか根拠の無い依存をする状態。これは完全なアンチパターンです。トラブルが起こってからテストコードを見直すと、酷い状態でした。
使用している言語や扱っているソフトウェアの規模、採用しているプロセスにもよるけれども、実際に「手動テスト」を実施していた時のように「テストコード」をレビューするのは現実的では無いと思う。レビュアーのスキルが高かったとしても(コードが問題無く読めるとしても)、「テスト仕様書」をレビューすることと「テストコード」をレビューすることの負荷は同等ではない。「テスト仕様書」はあくまで文書だから、人間が読解できるように最適化されているのに対して、「テストコード」はその展開された実装になってしまうからだ(DSLを使ってもカバーできる範囲には限界がある)。
だとしたら、どのように品質をおさえるべきなのか。個人的には、力点を「レビュー」から「評価」に移せばよいと考えている。確認する総量が増えたのであれば、「傾向を見て対策を行う」というアプローチが適している。
というわけで、現在時点の私のやり方をすこしだけ紹介してみる。アドバイスやコメントがあれば、ぜひともいただきたい。
- テストコードは必ず作成者以外のレビューを受けなければいけない。ピアレビュー必須。レビューをしたことを確認できるように記録する。
- 何らかの形でレビュー指摘数を記録する(コミットコメントなどで十分)。
- レビュー以外の方法でテストの網羅性を確認する。
- ツールによってカバレッジを検証する。
- 静的コード解析によって、コードの品質を検証する。
- テストで発見されて是正されたバグの数を記録する。
- コミットログから抜くのでも良い。ピアレビュー以降の修正をカウントする。
- テストコードから、(擬似的で良いので)テストケース数をカウントする。
- 上記情報を元に、「漏れ無く、ムラ無く」レビューとテストされているかを評価する。
- 偏ってないか
- 集中していないか
- 傾向がないか
- 怪しいと思った部分については強化レビュー実施
- 「誰が作ったのか」「誰がレビューしたのか」もチェックする
- 計画的なサンプリングチェックも実施する
- 第三者か、エースエンジニアにレビューさせる
- 恣意的に抽出しないよう、作戦を立ててサンプリングする
- 後続の工程とかリリース後にバグが出た時に、「テストコード」まで立ち返って分析をする
- なんで漏れたのか
- 他に漏れていないか
- 漏れた範囲は問答無用でテストコード修正(二度と漏れないようにする)
どうだろうか
追記(2012/4/12)
上記の文章に対して「そもそもxUnitのテストコードを書いたらテスト仕様書はいらないのか」という反応があった。個人的・経験的には、ある条件を満たしていれば(少なくとも単体レベルの)テスト仕様書の作成は省略できると思う。しかし、無条件に「xUnitのテストコードを書いたらテスト仕様書はいらない」ということは無いと考えているので注意いただきたい。
じゃあ、どういう条件があるのか、についてはまたどこかで整理したいと思っている。
