やぼったい開発 > コラム > JUnitの役割はどこまでか

コラム

JUnitの役割はどこまでか

試験工程内で 単体テストのできることとできないこと

あくまでコードレベルが範囲

UT工程はコードレベルを保証する工程で、JUnitはコードテストの自動化を補助するフレームワークであり、もちろん機能部分に対するツールではない(機能部分までテストによる動作保証は行えない)。


機能設計が正しければ、確かにUT部分の試験を通す事によって正しく機能が動いていることは保証できるが、機能の設計が正しいことは保証していないし、保証できない。



網羅率


UT部分であれば、網羅率(とりあえずパス網羅)は まずたいてい100%になるはず。

ちなみに、テストの仕方として、テスト対象の部分以外のコードは一時的にダミーを使用してもよく、また今度逆に、今ダミーとして用意したところをテストするのであれば、そこの部分は本物を用意してテストし、他のところはテストしやすくするためにダミーにしておこなう(あくまで「ダミーでなくてはいけない」ではなく、「ダミーにしてもいい」という話)。



100%にならないのは、予想では以下の3つの原因が考えられる。

  1. mockなどの使用法がわからない
  2. UT工程という部分がわかっていないため機能部分を含めてテストしてしまっているがために、ダミーが使えなくなり、網羅できない
  3. テストデータ(テスト条件)も ランダムに選んでいる

1つ目の対策として、うまくmockが使いこなせないようなのでmockや stubを作成する必要性を含めて試験の意図を説明する(単純に作成方法を説明しても、ぴんとこない)。


2つ目は開発の設計部分を担当していないとなかなかわかりづらいかもしれない。まず、上工程で業務レベル、機能レベル、処理レベルで大枠を意識しそれを保証するための試験を考える。

それからUT、機能試験ですべきこととすべきでないことを考えていく。

そうすればくっつけすぎたり分解すぎたり、細かすぎることはなくなっていき、質の良い試験書が作成できる。


3つ目について、70% 、90%から急に網羅率が上がらなくなるという理由を挙げる人はデータを適当に作っている可能性が高い。

もちろん適当にやっても網羅率が上がるが、品質を保証するためにはせめて網羅率を100%にすることが必要。

適当なデータでは網羅100%まで到達する確率が相当低い。
適当なデータでUTを行って、基準もなしにUTを完了させて不具合を流出させてしまうのであれば、なんで時間かけてUTしているの?その方法で進歩や改善はされるの?と質問したい。

※あと パス網羅だと、境界条件などが漏れる可能性があるので気を付けたほうがいい。



網羅に関して時間が無いという言い訳は、リソース的な話になるのでプロジェクト管理の話になる。

それでも、リスクヘッジや製品の品質保証説明のためにどの部分ができて、どの部分ができないかは明確にしておく必要がある。(ごっちゃになっていたり、適当な試験をしていると説明できない。)


余談:網羅率を Graphicalに表示するツールに Coberturaがある(ant,junitと連携するツール)。

<PR>リンク

類似コンテンツ

ウォータフォールモデルではテストファーストは当たり前?

なぜ自動化するのか?単体テスト自動化のメリットとデメリット

早わかり Junit 30分講座

単体試験と機能試験の違い



<<やぼったい開発へ戻る


http://www2.ocn.ne.jp/~cheerful/JUnit/
since (05/03/2006)
http://www2.ocn.ne.jp/~cheerful/develop/