技術的に誤った単体テストのコードカバレッジデータ - TechRepublic

質問

• 

  技術的に誤った単体テストのコードカバレッジデータ

  新入社員として入社した頃、製品コードのユニットテストスイートを調査していました。Gtestフレームワークを使用していました。しかし、すべてのテストを確認したところ、実際の関数を呼び出して期待される出力をアサートすることで、機能全体をテストしていました。以下は、そのようなテストケースの一例です。

  “`
  TEST(nle_26, UriExt1)
  {
  int スレッドID = 1;
  std::shared_ptre = std::make_shared(スレッドID、「./daemon.conf」);
  std::shared_ptrattr = e->initDefaultLSAttrib();
  e->setLSAttrib( attr );
  std::shared_ptrndb = e->initDatabase(データファイル、e->getLogger());
  e->loadASData(ndb);
  e->setVerbose();

  std::shared_ptrm = std::make_shared(e->getLogger());
  ASSERT_TRUE(m != nullptr);
  ASSERT_TRUE(e != nullptr);
  m->readFromFile(“../../msgs/nle1-26-s1”);
  e->scanMsg(m, &scan_callBack_26, NULL);
  std::map> Parts = e->verboseInfo.eventParts;
  std::vectoruris = Parts[“prt.uri”];
  ASSERT_EQ(uris.size(), 2 );
  ASSERT_EQ(uris[0] , “mailto:[email protected]”);
  ASSERT_EQ(uris[1] , “hotmail.com”);
  }
  “`
  ユニットテストディレクトリ内のすべてのテストが次のような同じパターンになっていることがわかりました。

  – 実際のオブジェクトの作成と初期化
  – 実際の関数の呼び出し
  – 実際のデーモンの起動
  – 約 45 MB のサイズの実際のデータベースのロード
  – 実際の scanMsg 関数の呼び出しなどによる、解析用の実際のメールのデーモンへの送信

  したがって、すべてのテストは、理想的には特定のユニットまたは関数コードについてテストする必要があるユニット テストではなく、機能テストまたは統合テストとして表示されます。

  しかし、重要なのは、公式イントラネット サイトで、gcov を使用して計算されたこの製品のコード カバレッジ パーセンテージが 73% と予測されていることです。

  現在、gcov などのコード プロファイリング ツールは次のパラメータのカバレッジを計算します。

  1. コードの各行が実行される頻度
  2. 実際に実行されるコード行
  3. コードの各セクションが使用する計算時間。

  これらのテストでは、実際のデーモンが実行され、実際のデータベースがロードされ、実際のネットワーク (ソケット) 呼び出しを含むメッセージをスキャンするための実際の関数が呼び出されます。

  そこで気になる疑問があります。
  どうやら、テストスイートは標準的な定義によれば、技術的に正しくないユニットテストのみで構成されているようです。では、そのようなテストスイートに対してgcovが生成したカバレッジは、信頼できるのでしょうか？[正直言って、私はそうは思いません。]

すべての答え