単体テストフレームワーク(xUnit)に関すること

このブログエントリの言いたいことがわかるようでわからなかったので、整理してみる記事。ドキュメントベースの単体テストとxUnitの類いの単体テストフレームワークの違いに関する私見。ツール(手段)の話ではなく、目的を中心に考えれば良いと思っている。

もし、ドキュメントベースの単体テストをそのまま踏襲したままで、xUnitを導入しようとするならば、もう一度テストの対象や目的を確認してください。xUnitは手段でしかありません。xUnitは小さなプログラムを動作確認するために作られたツールです。
ドキュメントベースの単体テストでxUnitを導入する前に考えて欲しいこと | DevelopersIO

ドキュメントベースの単体テスト

例えばこんな「ドキュメントベースの単体テスト」が行われていて、いきなりxUnit類のツールを適用するとかなり混乱すると思われる。

割と「単体テスト」というものを実施することがルールで強制されている
「単体テスト」の定義は無いか、ものすごく一般論な定義となっている
歴史的に「単体テストはこんなもん」という文化が形成されていて、わりと雰囲気でテストケース(テスト仕様)が文書化されている
文書化されたテストケース(テスト仕様)に従って、人間がテストを実施する。

こういった、時間によって叩き上げられたプロセスは、そこにあるツールやシステムに最適化されているものだ。

どの単位でテストを行うか
どうやってテストをするか
テストの品質を担保するために、どうやってドキュメントをレビューするか

ここでツール(例えばxUnit類)を導入しても、その特性は違うのでそのまま現状のプロセスに適用することは難しいだろう。テストの観点や粒度といったレベルで不整合が出てきて、結果としてストレス度の高い作業を行う必要が出てきてしまう。

単体テストの目的を整理する

既存のプロセスと新しいツール(例えばxUnit類)をいきなりマッピングしてしまうと面倒になってしまうので、ここは一歩下がって目的定義から確認すると良いと思う。使い方と使い方をぶつけてもうまくはいかないからだ。

プロジェクトによって異なるとは思うのだけれども、例えば自分の中では単体テストは次のように定義している。

テスト可能な最小単位のコンポーネント毎に、ホワイトボックス観点でのテストを実施する。必要に応じてスタブ・ドライバ等を作成し、テスト対象コンポーネントが意図した挙動をすることを確認する。
除去を意図する主要な品質リスクは「コーディングミス」「上流工程成果物の落とし込み漏れ」である。

こう定義した上で、効果的に品質リスク(つまりバグ)を除去するためにどうするかを考えるというステップを踏めばよいと思う。

例えば、

コーディングミスを防止する為に、強めのコンパイルオプションで細かいエラーをつぶす
コーディングミスを防止する為に、静的解析ツールをかける
xUnit類を使って、ほぼ全てのコード行が実行可能かつ意図した結果となることを確認する
- xUnit類でテストできないコードは別の手段で確認する(レビューの場合も含む)
xUnit類が使えない、又は効率的ではない部分は、別の手段でテストする

というような整理を行えばいいのではないかと思う(というか、自分はそうしている)

どんなバグを取りたいのかについて考える

ソフトウェアの最終品質を考える際に、どのタイミングで、どんな方法を使ってバグを摘出するかを考えるとイメージしやすいと思っている。ちょっと古いけれども個人的には「基本から学ぶソフトウェアテスト」の付録についている「よくあるソフトウェア不具合」のリストをよく見返している。ただひたすらバグの原因が列挙されているリストで、読んでいるだけでお腹が痛くなってくるのだけれどもイメージトレーニングに良い。