GoogleTest：README に記載されたビルドと統合の方法

GoogleTest: リポジトリの内容と README の焦点

google/googletest リポジトリは、Google の C++ テスト・モッキングフレームワークである GoogleTest として自己記述しています。README はほぼすべてビルド手順です：フレームワークのコンパイル方法と、自分のテストにリンクする方法を説明しています。個々のアサーションマクロの解説やテスト作成の例はなく、設定マクロの完全なリストは include/gtest/internal/gtest-port.h を参照するよう指示しています。

GoogleTest: 主要なビルド経路としての CMake

リポジトリには CMakeLists.txt スクリプトが含まれており、README は CMake をクロスプラットフォームと述べています。GoogleTest はスタンドアロンプロジェクトとしてビルドするか、既存の CMake ビルドに組み込むことができます。CMake は選択したコンパイラ環境に合わせてネイティブな makefile またはビルドプロジェクトを生成するため、Unix、Windows、macOS の各ツールチェーンで同じスクリプトが機能すると README は述べています。

GoogleTest: README のスタンドアロンビルド手順

文書化されたスタンドアロンのワークフローは、`git clone https://github.com/google/googletest.git -b v1.17.0` で始まり、`build` ディレクトリを作成して `cmake ..` を実行します。このコマンドは GoogleTest と GoogleMock の両方をビルドします。GoogleMock を無効にするには `-DBUILD_GMOCK=OFF` を追加します。Unix 系では Makefile が生成され、`make` でビルド、`sudo make install` でデフォルトの /usr/local にインストールされます。Windows では gtest.sln が、macOS では .xcodeproj が生成されます。

GoogleTest: 既存の CMake プロジェクトに GoogleTest を組み込む

すでに CMake を使用しているプロジェクト向けに、README は2つの方法を示しています。1つは `find_package(GTest CONFIG REQUIRED)` を使い、`GTest::gtest` と `GTest::gmock` をリンクする方法です。もう1つは、より堅牢で柔軟とされる `add_subdirectory()` または FetchContent を使う方法です。README の例では `FetchContent_Declare` で特定のコミットの URL を指定し、`FetchContent_MakeAvailable(googletest)` を呼び出します。このコマンドのため CMake 3.14 以降が必要です。

GoogleTest: C++ 標準と設定マクロ

README は、GoogleTest のビルドに C++17 をサポートする環境が必要だと述べています。`CMAKE_CXX_STANDARD 17` と `CMAKE_CXX_STANDARD_REQUIRED ON` を設定するか、グローバルに設定できないプロジェクトでは `-DCMAKE_CXX_FLAGS` で標準を渡すことを提案しています。動作を調整するために、`GTEST_XYZ` のような名前の制御マクロをコンパイラコマンドラインで 1 または 0 に定義し、完全なリストは gtest-port.h を参照するよう説明しています。

GoogleTest: スレッド安全性と共有ライブラリビルド

README によると、GoogleTest は pthread が利用可能な環境でスレッドセーフです。gtest/gtest.h をインクルードした後、`GTEST_IS_THREADSAFE` マクロが 1 に定義されているか、未定義であるかで判断できます。検出が誤っている場合は `-DGTEST_HAS_PTHREAD=1` または 0 で強制できます。共有ライブラリをビルドするには、gtest のコンパイル時に `-DGTEST_CREATE_SHARED_LIBRARY=1`、テストのコンパイル時に `-DGTEST_LINKED_AS_SHARED_LIBRARY=1` を追加します。一部のコンパイラでは現在不要でも、将来必要になる可能性があると README は注意しています。

GoogleTest: マクロ名の衝突を避けるためのリネーム

C++ のマクロは名前空間を無視するため、同じ名前のマクロを定義する2つのライブラリは衝突します。README では、`-DGTEST_DONT_DEFINE_FOO=1` を定義すると GoogleTest がマクロをリネームできると説明しています。`FOO` には `ASSERT_EQ`、`EXPECT_TRUE`、`TEST` などのアサーションまたはテストマクロが該当します。例えば `-DGTEST_DONT_DEFINE_TEST=1` を使うと、`TEST(SomeTest, DoesThis)` の代わりに `GTEST_TEST(SomeTest, DoesThis)` と書く必要があります。対応するマクロのリストは README に記載されています。

GoogleTest のビルドを既存プロジェクトへ組み込むときは、依存の取得方法と標準設定を一緒に固定します。README が示す find_package は事前に構成されたパッケージを探し、GTest::gtest と GTest::gmock をリンクする経路です。add_subdirectory や FetchContent はソースをプロジェクトのビルドへ取り込む経路で、後者の例は特定コミットの URL を宣言してから FetchContent_MakeAvailable(googletest) を呼びます。CMake 3.14 以降が必要とされています。C++17 が必要なため、CMAKE_CXX_STANDARD と CMAKE_CXX_STANDARD_REQUIRED を設定し、コンパイラが実際にどの標準で動いたかをログで確認します。pthread の検出は GTEST_IS_THREADSAFE で確認でき、必要なら GTEST_HAS_PTHREAD を指定します。共有ライブラリではビルド側とテスト側で異なるマクロを指定するため、設定を片方だけに置かないことが重要です。

GoogleTest と GoogleMock は同じリポジトリからビルドされますが、README には -DBUILD_GMOCK=OFF で GoogleMock を無効にする選択肢があります。既存の CMake プロジェクトでどちらを必要とするかを先に決め、不要なターゲットをリンクしない構成にします。テスト実行時は個別テスト、順序指定、並列実行など複数の方法があると README は説明しています。実行器や IDE の統合を使う場合、GTest Runner、GoogleTest UI、TAP listener などは本体とは別の関連プロジェクトです。Chromium、LLVM、Protocol Buffers、OpenCV が利用例として挙げられていますが、これらの採用事例は自分の環境で同じ結果になることを意味しません。まず一つの小さなテストをビルドし、失敗時の出力と設定マクロを保存してから対象範囲を広げます。

テスト対象のプロジェクトが独自の TEST マクロを持つ場合は、GTEST_DONT_DEFINE_TEST=1 を指定し、GTEST_TEST へ書き換える方法が README に示されています。ASSERT_EQ や EXPECT_TRUE などにも同様のリネーム設定があります。マクロは名前空間で隔離されないため、ヘッダーを混ぜた時点で衝突する可能性があります。まず最小構成でヘッダー、リンク対象、実行ファイルを確認し、共有ライブラリへ移る場合は gtest 側とテスト側の設定を同時に点検します。

編集部の結論

README の範囲は GoogleTest のビルドと統合に集中しており、テストの書き方やベンチマークには触れていません。BSD-3-Clause ライセンスは条件付きで再配布を許可し、保証を否認しています。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes