実装したコードに着目して行われるホワイトボックステスト。その中のステートメントカバレッジ(命令網羅)というのがあります。いわゆるC0(シーゼロ)と呼ばれるこのテストですが、個人的にはどう考えても「単体テスト」の要素になり得ないと思ってます。何故こんなのにC0と名前をつけてしまうのか・・・

条件分岐でどう分岐しようが、繰り返し処理で何回繰り返そうが関係なく、単純に「書いてあるコード」が1回でもパスすれば「ステートメントカバレッジが100%」と判断できるという最も簡単なホワイトボックステストのテストレベルです。もともと私は機能要件を満たせば(もちろん例外も想定して)ステートメントなんてカバーしてなくても問題ないと考えているタチなので、無条件に通れば良いこのテストには全くもって賛同できません。

機能でテスト(繰り返しますが、例外も十分に想定して)でパスしないステートメントなんて無駄な実装もいいところだと思います。C0に限らずC1、C2にも言えることですが、単純にステートメントを通してカバレッジ100%と主張してくるも、実は数10%のコードが意味のない(或いは冗長な)コードだったというプロジェクトもざらです。C0は条件分岐のパターンや繰り返しの目的等を汲まないテストであるため、間違った実装が間違った仕様としてテストされるというのもよく見かけます。

結局のところ、過不足なく機能が実装できていて、小さな処理ブロック単位でしっかりと設計されているプログラムでないとホワイトボックステストは意味をなさないと思います。特に「書いたコードが意図した通りに動く」というC0のテストレベルは、いくら単体テストの工数が足りなかったとしても妥協できるレベルには到底足らないむしろ「それくらい実装時点で終わらせておいてよ」とも言える開発時の疎通確認レベルと言えるのではないでしょうか。

まじめに開発していれば「命令網羅C0」なんて開発中に全てパスします。それを「単体テスト」として切り離すもんだから、「とりあえず実装したけど、動くかどうかはわかりません。単体テストでテストします。」なんてセリフがまかり通る。そしてバグが見つかるとそれが機能を満たすのに必要ないものであっても「品質があがった。良いテストができた。」と判断され修正実装が行われ再び単体テストに入るという数週間規模のロスを伴う悪循環が生まれます。C0が単体テスト基準の1つと思っているうちは避けられないと思います。

にほんブログ村 IT技術ブログへ
にほんブログ村
にほんブログ村 IT技術ブログ IT技術情報へ
にほんブログ村

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です