JUnitは品質にどれだけ寄与するか?

JUnitがこれだけ世の中に広まったということは、その効果は多くの人が認めるところでしょう。
ただ、その一方で、単に「JUnitを利用するだけで品質が向上する」と思われているような状況には、危惧を感じます。


まず、JUnitの特徴をまとめると、以下のようになるでしょう。

  • メリット
    1. 実装したコードが動作することを確認できる
    2. リグレッションテストにより、デグレを防げる
    3. リファクタリングしやすい
  • デメリット
    1. カバレッジだけでは、品質分析がしにくい
    2. 実コードよりもテストコードの方を多く作成することになる
    3. コードの動作は確認できても、それが「仕様を満たしている」保証はない


ここで、
コードの動作は確認できても、それが「仕様を満たしている」保証はない
というのが、一番やっかいな問題です。


ブログや技術雑誌で、「JUnitでテストケースを作成していれば、単体試験仕様書は要りません」なんて記事をよく目にしますが、そんなことはないでしょう。

「動作する」と「仕様を満たす」ということは別のことであり、JUnitは基本的に前者が対象です。
後者は、作成したテストコードの質に依存する、つまり、実装者に依存するため、仕様がヌケていても間違って実装されていても、テストはグリーン(OK)の状態になってしまいます。


例えば、以下のようなBadパターンが良くあります。

  • 一覧を取得するケースで、件数はチェックしていても、その内容は確認していない
  • ログ出力を確認していない
  • 複数の条件からなる分岐で、実は条件を網羅していない(カバレッジは行で判定されるため、見逃しやすい)


経験的には、テストコードは実コードの2〜3倍程度の規模になります。そのため、作成しているテストコードの質が悪く、バグや実装ヌケが見逃されるようなテストコードを作成していては、かけた分の工数が無駄になってしまいます。


私の場合は、テストコードをレビューしたり、そのコメントに試験条件/確認内容を書き、それをレビューしたり、ということを行いますが、それぐらいはしないと、品質を作り込むことはできないと考えています。


TDDにより、実装の開始時点から品質を作り込んでいく流れは、非常に良いものだと思いますし、私も実際にプロジェクトで利用しています。


ただ、暗黙的にJUnitを利用しているだけでは、プロジェクトは成功しないと思うところです。