ホワイトボックステストにおけるカバレッジ（C0/C1/C2/MCC）について - Qiita
本稿では以下のサンプルコードを用いて、ホワイトボックステストにおけるカバレッジ（C0/C1/C2/MCC）について説明します。 if(条件文a1 || 条件文a2){ // 判定条件A 命令文X; } if(条件文b1 || 条件文b2){ // 判定条件B 命令文Y; } else{ 命令文Z; } 命令網羅 (statement coverage) (C0) それぞれの命令文が少なくとも1回は実行される ようにテストを設計します。上記のサンプルコードの場合、カバレッジ率を100%にするためのテストケース数は2通りとなります。 テストケースNo. 条件文a1 条件文a2 条件文b1 条件文b2 判定条件A 判定条件B 命令文X 命令文Y 命令文Z
「カバレッジが高ければ、品質が高い」と誤解している危険な思想家の皆様へ - Qiita
皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
