gmockのマッチャーをプリコンパイル済みヘッダーでまとめてusingする

[berryzplus]

PR対象

• テストコード

カテゴリ

• 改善

PR の背景

プロジェクトのテストアサーションの書き方に微妙に統一感がない。

従来の書き方例

    ASSERT_STREQ(expected, actuial);

GMockの定義済みマッチャー群をまとめて using することにより、統一感および書きやすさの向上を図ります。

仕様・動作説明

• Pull Request 自体は using の追加のみなので、直接の影響はありません。

変更後の書き方例

    EXPECT_THAT(actuial, StrEq(expected));

PR の影響範囲

• using追加のみなので、影響はありません。

テスト内容

• using追加のみなので、テストできる変更がありません。

• テスト実行結果による評価は不可能です。

関連 issue, PR

• メッセージボックスのテストを追加する #2068
  このPull Requestの変更を含んでいます。
  「既存テストの拡充に必要な変更」の位置づけになります。

参考資料

[m-tmatma]

変更後の書き方 の場合何がメリットあるんですか?
従来の書き方 の場合の問題点がわかってないです。

[berryzplus]

変更後の書き方 の場合何がメリットあるんですか? 従来の書き方 の場合の問題点がわかってないです。

EXPECT_THATは「actual が expected である」をチェックします。
今回のPull Requestでは「expected である」の詳細を指定する述語関数の「::testing::」を省略できるようにしています。

こういうテストを書きたいときに便利です。

次のような、必ず失敗するテストケースがあるとします。

	EXPECT_STREQ( L"expected", L"actuial" );
	EXPECT_THAT( L"actuial", ::testing::StrEq(L"expected") );

実行結果はこんな感じになります。

#1 - Expected equality of these values:
  L"expected"
  L"actuial"
#2 - Value of: L"actuial"
Expected: is equal to L"expected"
  Actual: L"actuial" (of type wchar_t const [8])

従来の書き方「EXPECT_EQ」だと与えた2つの引数が意味付けされません。（どちらが結果でどちらが期待値かわからない。）

後者のほうが分かりやすいと思いますが、いかがでしょうか。

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[m-tmatma]

意図を理解しました

[berryzplus]

レビューありがとうございます。

マージは2approveされた時点、または、最初のapproveから1週間経過後でやっているのでしばらくお待ちください。。