ユニットテストの網羅性の扱いについて - 千里霧中

テストの網羅性については様々なものがある。基本的な網羅性の観点としては、構造ベース、仕様ベース、外部の標準や指標ベースなどが挙げられる。 そして観点ごとに、様々な網羅性の指標がある。ユニットテストの場合だと、例えば以下がある。 コードの構造網羅 コードの構造を網羅する。ここでいうコードの構造としては、制御フロー、データーフロー、例外フローなどがある。具体的な指標としては、コードカバレッジが有名。コードの構造網羅では、コードカバレッジなどを基準にして、基準以上の網羅性を確保できるようにテストを設計する。 なお、構造網羅というと、一般的な定義ではコード以外の構造も扱われるが、このブログでは便宜上「構造網羅をコードの構造を網羅すること」という定義に絞り込んで説明する。 仕様網羅 コードの仕様を網羅する。コードの仕様には、対象（対象の粒度はテストレベルに依存する。例えば関数やクラス、モジュールを単

[Steiger31226]

“構造”

[green_abc]

“仕様網羅が有効になる。関数やクラスの仕様を満たしているか網羅的に検証することによって、機能的な保障が可能になる上、構造網羅で見逃しがちな未実装バグや冗長な実装を検出できる。”

[sugimori]

やっぱり行き当たりばったりでないメソッドが必要だな。

[ryuzee]

「この構造網羅と仕様網羅のどちらを重視するかは、テストの目的による」そうそう。

[hidehish]

見てる:

[kaorun55]

あとでよむ=>読んだ。テスト設計の話。

[yuno001]

単体テストの構造網羅と仕様網羅について

[yujiorama]

どんなコンテキストが前提なのか気になりました

[irof]

「何の網羅」かはとても重要。構造網羅率は 85-95% が良いらし（100%はむしろ危険とか）。