C++ユニットテストにGoogleTestが選ばれる理由｜Catch2との違い

C++ プロジェクトにユニットテストを入れると決めたあと、最初に立ち止まるのが「どのフレームワークを選ぶか」という問いです。候補として名前が挙がるのは GoogleTest、Catch2、doctest あたりで、いずれも広く使われています。

ところが、比較しようとして各プロジェクトの機能一覧を並べても、なかなか差が見えてきません。どれも「アサーションが豊富」「テストの自動検出に対応」「CMake で導入できる」と書かれており、決め手になる違いが機能リストの粒度では表面化しないためです。しかも 3 つとも活発にメンテナンスされているため、更新頻度で足切りすることもできません。

結論から言うと、この 3 つの選定は「モック機能が必要か」「ビルド時間が制約になるか」「プロジェクトが要求できる C++ 規格はどこまでか」という 3 つの軸でほぼ決まります。機能の網羅性ではなく、この 3 軸に自分のプロジェクトを当てはめることが、遠回りしない選び方です。

本記事では、GoogleTest の公式ドキュメント・README と、GitHub API（gh api）で取得したリポジトリメタデータを基に、GoogleTest の位置づけ・主要機能・導入手順を整理し、Catch2・doctest・Boost.Test との違いと選定の判断軸を解説します。実行環境の構築やコードの動作検証は行わず、公開ドキュメントに記載された事実のみを扱います。掲載するコードはすべて公式ドキュメントからの引用で、引用直後に出典を明記します。

GoogleTestとは｜GoogleのC++テスト・モック統合フレームワーク

GoogleTest は Google が開発・公開している C++ 向けのテストフレームワークです。GitHub 上のリポジトリ google/googletest では、自身を「GoogleTest - Google Testing and Mocking Framework」と説明しています。名前のとおり、テスト（Testing）とモック（Mocking）の両方を守備範囲に含めている点が、この後の比較で効いてきます。

ドキュメントは GitHub Pages 上の GoogleTest User's Guide に集約されており、README でもリポジトリ内のファイルを直接読むよりこちらを参照することが推奨されています。

リポジトリ基本情報

GitHub API で取得した 2026 年 9 月 2 日時点のリポジトリ情報は以下のとおりです。

アーカイブされたリポジトリでもフォークでもなく、ライセンスも明示されている、通常の現役プロジェクトです。最終 push が調査日の前日であることからも、日常的に更新が入っている状態が読み取れます。

README の「Who Is Using GoogleTest?」では、採用プロジェクトとして Chromium プロジェクト（Chrome ブラウザおよび ChromeOS）、LLVM コンパイラ、Protocol Buffers、OpenCV が挙げられています。いずれも大規模かつ長期運用される C++ プロジェクトであり、大規模コードベースでの実績という観点では判断材料になります。

GoogleTestとGoogleMockが同一リポジトリである意味

README には、このリポジトリが「かつて別々だった GoogleTest プロジェクトと GoogleMock プロジェクトを統合したもの」であり、両者は密接に関連しているため一体でメンテナンス・リリースしていると記載されています。

これは単なる歴史的経緯にとどまりません。テストフレームワークとモックフレームワークを別々のライブラリで組み合わせる場合、両者のバージョン整合や、アサーション失敗時のレポート形式の食い違いに注意を払う必要があります。GoogleTest はこの組み合わせ問題を、同一リポジトリ・同一リリースサイクルという形で構造的に解消しています。後述する比較では、これが Catch2・doctest との最も大きな差分になります。

GoogleTestの主要機能｜アサーション・フィクスチャ・パラメータ化テスト

README の Features に列挙されている機能を整理すると、次のようになります。

網羅的な API 解説は公式ドキュメントに譲り、ここでは採用判断に必要な「書き味」が分かる 3 点に絞ります。以下のコードはすべて公式の GoogleTest Primer からの引用です。

ASSERT_とEXPECT_の使い分け

GoogleTest のアサーションは 2 系統に分かれています。ASSERT_* は致命的な失敗（fatal failure）を発生させ、その時点で関数を中断します。EXPECT_* は非致命的な失敗（nonfatal failure）を発生させ、テストの実行を継続します。

公式ドキュメントは「通常は EXPECT_* が推奨される。1 つのテストで複数の失敗を報告できるためである。ただし、そのアサーションが失敗した状態で処理を続ける意味がない場合は ASSERT_* を使うべきである」と述べています。この基準は明快で、ヌルポインタチェックのように後続処理が成立しなくなる箇所は ASSERT_*、独立した複数の値を検証する箇所は EXPECT_* という切り分けになります。

アサーションには << でカスタムメッセージを付加できます。

ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";

出典: GoogleTest Primer

TESTとTEST_F（フィクスチャによる前提の共有）

個々のテストは TEST() マクロで定義します。第 1 引数がテストスイート名、第 2 引数がテスト名です。

TEST(TestSuiteName, TestName) {
  ... test body ...
}

TEST(FactorialTest, HandlesZeroInput) {
  EXPECT_EQ(Factorial(0), 1);
}

出典: GoogleTest Primer

複数のテストで同じオブジェクト構成を使い回したい場合は、testing::Test を継承したテストフィクスチャを定義し、TEST_F() で参照します。

class QueueTest : public testing::Test {
 protected:
  Queue<int> q0_;
  Queue<int> q1_;
};

TEST_F(QueueTest, IsEmptyInitially) {
  EXPECT_EQ(q0_.size(), 0);
}

出典: GoogleTest Primer

TEST と TEST_F の 2 段構えは xUnit 系フレームワークに共通する作法で、チームに Java や C# のテスト経験者がいる場合、記述スタイルの学習コストが低く済むという特性があります。

テストの起動とgtest_main

テストの実行は RUN_ALL_TESTS() が担い、すべて成功すれば 0、1 つでも失敗すれば 1 を返します。自前で main を書く場合は次の形になります。

int main(int argc, char **argv) {
  testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

出典: GoogleTest Primer

ただし多くの場合、この main を自分で書く必要はありません。GoogleTest は gtest_main というライブラリを提供しており、これをリンクすれば標準的な main が供給されます。のちほど紹介する CMake の最小構成でも、この gtest_main をリンクする形になっています。

GoogleMockが同梱される価値｜依存分離とインタラクション検証

GoogleTest を他のフレームワークと分ける最大のポイントが、モックフレームワークである GoogleMock（gMock）を同梱していることです。以下の内容とコードは公式の gMock for Dummies に基づきます。

モックが必要になる場面

公式ドキュメントはモックオブジェクトを「実オブジェクトと同じインターフェースを実装しつつ、実行時にどのように使われ、何を返すべきかを指定できるもの」と定義し、動くけれども手を抜いた実装である fake と明確に区別しています。モックは「事前に設定した期待（expectations）」を持つ点が本質です。

モックが有効な場面として、公式ドキュメントは次のようなケースを挙げています。

• 不要な依存を切り離してテストを高速化する
• 実オブジェクトでは再現しにくい失敗シナリオを検証する
• モジュール間のインタラクション（呼び出し関係）そのものを検証する
• 実装が未完成な段階でインターフェースをプロトタイピングする
• データベースやネットワークのような不安定・高コストなリソースを置き換える

このうち 3 つ目の「インタラクションの検証」は、戻り値の比較だけを行うアサーションでは表現できない領域です。「保存処理が確かに 1 回だけ呼ばれたか」「リトライが最大 3 回で打ち切られたか」といった検証は、モックがなければ実装しにくくなります。

MOCK_METHODによるモッククラス定義

モッククラスは、対象インターフェースを継承したうえで MOCK_METHOD マクロを並べる形で定義します。

#include <gmock/gmock.h>

class MockTurtle : public Turtle {
 public:
  MOCK_METHOD(void, PenUp, (), (override));
  MOCK_METHOD(void, PenDown, (), (override));
  MOCK_METHOD(void, Forward, (int distance), (override));
  MOCK_METHOD(int, GetX, (), (const, override));
};

出典: gMock for Dummies

マクロの引数は「戻り値型・メソッド名・引数リスト・修飾子（const や override）」の順です。定型的な記述で済むため、インターフェースが定義されていればモック実装を機械的に用意できます。

EXPECT_CALL・マッチャー・カーディナリティ

期待の設定は EXPECT_CALL で行います。一般構文は次のとおりです。

EXPECT_CALL(mock_object, method(matchers))
    .Times(cardinality)
    .WillOnce(action)
    .WillRepeatedly(action);

出典: gMock for Dummies

実際のテストでは次のように書きます。

using ::testing::Return;
using ::testing::AtLeast;

TEST(PainterTest, CanDrawSomething) {
  MockTurtle turtle;
  EXPECT_CALL(turtle, PenDown())
      .Times(AtLeast(1));

  Painter painter(&turtle);
  EXPECT_TRUE(painter.DrawCircle(0, 0, 10));
}

出典: gMock for Dummies

引数の照合にはマッチャーを使います。_ は任意の値にマッチするワイルドカードで、Ge(100) のような比較マッチャーも用意されています。

using ::testing::_;
using ::testing::Ge;

EXPECT_CALL(turtle, GoTo(50, _));
EXPECT_CALL(turtle, Forward(Ge(100)));

出典: gMock for Dummies

呼び出し回数を指定する Times() は省略でき、その場合 gMock がカーディナリティを推論します。WillOnce も WillRepeatedly も指定がなければ Times(1)、WillOnce が n 個並んでいれば Times(n) と解釈されます。

呼び出し順序の検証と設定順の制約

呼び出しの順序まで検証したい場合は InSequence を使います。

using ::testing::InSequence;

{
  InSequence seq;
  EXPECT_CALL(turtle, PenDown());
  EXPECT_CALL(turtle, Forward(100));
  EXPECT_CALL(turtle, PenUp());
}

出典: gMock for Dummies

導入前に押さえておきたい制約が 1 つあります。公式ドキュメントは「gMock は期待をモック関数が呼び出される前に設定することを要求しており、そうでない場合の挙動は未定義である」と明記しています。テスト対象を先に実行してから後付けで期待を検証する、という書き方はできません。この点は、テストの書き方そのものに影響するため、チームで共有しておく価値があります。

CMakeでのGoogleTest導入手順｜FetchContentによる最小構成

採用可否を判断するうえで、導入コストの見積もりは欠かせません。ここでは公式の Quickstart: Building with CMake が示す最小構成を確認します。目的は「選定後に最短で動かし始めるための最小形」を把握することなので、vcpkg や Conan などのパッケージマネージャ経由の導入やビルドオプションの網羅には踏み込みません。

前提条件

公式の要件は CMake 3.14 以上、そして C++17 です。既存プロジェクトの CMake が古い場合は、まずここが移行の第一関門になります。

FetchContentで取得するCMakeLists.txt

公式が提示する最小の CMakeLists.txt は次の内容です。

cmake_minimum_required(VERSION 3.14)
project(my_project)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

include(FetchContent)
FetchContent_Declare(
  googletest
  URL https://github.com/google/googletest/archive/03597a01ee50ed33e9dfd640b249b4be3799d395.zip
)
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
FetchContent_MakeAvailable(googletest)

出典: Quickstart: Building with CMake

注目したいのが 2 点あります。1 つは FetchContent_Declare の URL がブランチ名やタグ名ではなくコミットハッシュを指していることで、公式は「最新版を指すよう定期的に更新すること」を推奨しています。取得内容を固定して再現性を担保しつつ、更新をチームの管理下に置く方針です。もう 1 つは gtest_force_shared_crt ON で、これは Windows 環境で C ランタイムの設定を揃えるためのオプションです。

最初のテストとgtest_discover_tests

テストターゲットの定義とテスト登録は次のように書きます。

enable_testing()

add_executable(
  hello_test
  hello_test.cc
)
target_link_libraries(
  hello_test
  GTest::gtest_main
)

include(GoogleTest)
gtest_discover_tests(hello_test)

出典: Quickstart: Building with CMake

GTest::gtest_main をリンクしているため、先に触れたとおり main 関数を自分で書く必要はありません。gtest_discover_tests は実行ファイル内のテストを検出して CTest に自動登録するコマンドで、テストを追加するたびに CMake 側へ登録を書き足す作業が不要になります。

テスト本体は次のような最小構成です。

#include <gtest/gtest.h>

TEST(HelloTest, BasicAssertions) {
  EXPECT_STRNE("hello", "world");
  EXPECT_EQ(7 * 6, 42);
}

出典: Quickstart: Building with CMake

なお Windows 環境では、Visual Studio 2017 以降で「C++ によるデスクトップ開発」ワークロードの既定コンポーネントとして GoogleTest が統合されているという記述があります（Google Test for C++ を使用して単体テストを作成して実行する - Microsoft Learn）。Visual Studio 中心のチームでは、CMake での取得を経由せずに導入できる可能性があります。

C++テストフレームワーク比較｜Catch2・doctest・Boost.Testとの違い

ここからが選定の中核です。GoogleTest と主要な代替候補を、実務で差が出る観点に絞って比較します。

主要フレームワークの比較

スター数・ライセンス・最終 push は 2026 年 9 月 2 日時点で GitHub API から取得した値です。

表の読み方について 2 点補足します。

1 点目は Boost.Test のスター数についてです。211 という数字は他の 3 つと比べて桁違いに小さく見えますが、これは Boost が boostorg/boost を中心に多数のモジュールへ分割されているリポジトリ構造に起因するもので、実利用規模を示す指標ではありません。Boost.Test は description が示すとおり「the reference C++ unit testing framework」であり、C++03 まで対応範囲が広い点が特徴です。すでに Boost に依存しているプロジェクトでは第一候補になり得ますが、本記事では主な比較対象を Catch2 と doctest に置きます。

2 点目はコンパイル時間です。doctest はプロジェクト名のとおりビルド時間の短さを前面に出しており、Catch2 や GoogleTest と比較して大幅にコンパイル時間を削減できるという指摘があります（C++ Unit Testing Frameworks in 2026 | hacking C++、Master C++ Testing: GoogleTest vs Catch2 vs doctest Guide |…）。ただしこれらは第三者による測定であり、削減率は測定環境やテストコードの規模に依存します。自プロジェクトでビルド時間が主要な制約になっている場合は、実測して判断する前提で扱うのが妥当です。

モックの有無が最初の分岐になる理由

比較表の中で、あとから覆しにくいのがモック機能の有無です。

Catch2 と doctest はモック機能を同梱していません。これは設計上の欠落ではなく、テストランナーとアサーションに責務を絞るという設計判断です。したがって、これらでインタラクション検証を行う場合は FakeIt や Trompeloeil といった外部のモックライブラリを併用することになります。組み合わせ自体は成立しますが、依存関係が 1 つ増え、バージョン更新のたびに 2 つのライブラリの互換性を確認する運用が発生します。

一方 GoogleTest は、先に述べたとおり GoogleMock を同一リポジトリで統合的にリリースしています。テストとモックのバージョン整合を考える必要がなく、失敗レポートの形式も統一されています。

つまり「テスト対象がインターフェースを介して外部依存を持ち、その呼び出し関係を検証する必要があるか」が、最初に判定すべき分岐点になります。ここが Yes なら GoogleTest が最も摩擦の少ない選択になり、No なら残り 2 軸で決められます。

用途別の選び方

3 軸を順に当てはめると、選定は次のように整理できます。

軸 1: モックが必要か インタラクション検証や外部依存の切り離しが必要なら GoogleTest。モックライブラリを別途組み合わせる運用コストを許容できる場合に限り、他の選択肢が残ります。

軸 2: ビルド時間が支配的か テストコードのコンパイル時間が開発サイクルのボトルネックになっている、あるいは組込み・ヘッダオンリーライブラリのようにビルド回数が多い場合は doctest が有力です。単一ヘッダで外部依存がないため、導入の摩擦も最小です。

軸 3: 要求できる C++ 規格と記述スタイル GoogleTest の v1.18.x は C++17 以上を要求します。プロジェクトを C++14 以下に留める必要がある場合、この時点で GoogleTest は候補から外れ、Catch2 の v3 系（C++14 以上）や v2.x 系（C++11 以上）、あるいは doctest（C++11 以上）が選択肢になります。規格に余裕があるうえで、SECTION や SCENARIO による BDD 的な記述で仕様を表現したいなら Catch2 が向きます。逆に、xUnit 系の作法をチーム共通の型として揃えたいなら GoogleTest が自然です。

GoogleTest採用前に確認したいメンテナンス状況とライセンス

選定の最後に確認すべきは、選んだあと数年にわたって使い続けられるかという観点です。

リリース頻度とサポートポリシー

GitHub API で取得した直近のリリース履歴は次のとおりです。

タグ付きリリースはおおむね年 1〜2 回のペースで、最終 push は 2026 年 9 月 1 日です。リリース間隔は決して短くありませんが、日々のコミットは継続的に入っており、更新が止まったプロジェクトではないことが確認できます。

サポート対象のコンパイラ・プラットフォーム・ビルドツールは、Google の Foundational C++ Support Policy に従うとされています。具体的な対応バージョンの一覧は foundational-cxx-support-matrix.md に集約されているため、自チームのコンパイラが対象範囲に入っているかは、採用判断の段階でこの表を確認しておくのが確実です。ポリシーは Google の OSS 全体に適用される横断的なもので、GoogleTest 単独の裁量で決まるわけではない点も、予測可能性という意味では利点になります。

C++17要件がもたらす移行コスト

v1.18.0 のリリースノート には、最低要件が C++17 に引き上げられたことが明記されています。これは上記のサポートポリシーに整合させるための変更で、C++17 が string_view を保証することから GTEST_INTERNAL_HAS_STRING_VIEW が 1 に設定される、といった内部的な前提の変化も伴います。

既存プロジェクトを C++11 や C++14 でビルドしている場合、GoogleTest の最新版に追随するにはコンパイラとビルド設定の更新が前提になります。テストフレームワークの導入がプロジェクト全体の規格引き上げを引き連れてくる形になるため、導入コストの見積もりには、この移行分を含めて考える必要があります。

もう 1 点、運用方針として押さえておきたいのがブランチの扱いです。リリースノートでは、v1.18.x ブランチには新機能のパッチを受け付けず、例外的な重大バグ修正のみを検討する方針が示されています。それ以外については最新のコミットからビルドすることが推奨されています。タグ付きリリースだけを追う運用にすると、修正の取り込みが遅れる可能性があるということです。先の CMake 設定で FetchContent の URL がコミットハッシュ指定になっていたのは、この運用方針と対応関係にあります。

ライセンスと将来の依存関係

ライセンスは BSD-3-Clause です。商用利用が可能で、条件は著作権表示とライセンス条文の保持、および contributor 名を無断で推奨表示に使わないことです。テストコードは製品バイナリに含まれないケースが多いとはいえ、配布物にテストバイナリを含む場合はライセンス表記の扱いを確認しておくのが安全です。

もう 1 点、README のアナウンスには「Coming Soon」として Abseil（abseil-cpp）への依存を追加する計画が記載されています。これは現時点では計画として告知されている段階であり、実施時期や具体的な影響範囲は確定していません。ただし、依存ライブラリが増えることはビルド構成やライセンス管理に影響し得るため、長期運用を前提とするプロジェクトでは、今後のリリースノートを追跡対象に含めておくとよいでしょう。

周辺エコシステムについては、README の「Related Open Source Projects」に、並列実行ランナーの gtest-parallel、VS Code 拡張の GoogleTest Adapter および C++ TestMate、TAP プロトコル出力の GTest TAP Listener、GUI ランナーの GTest Runner などが列挙されています。CI での並列化やエディタ統合といった実運用上の要求に対して、既存のツールを選べる状況があることは、採用後の拡張余地として評価できます。

まとめ｜GoogleTestが適するプロジェクトの条件

冒頭に挙げた 3 つの問いに対する回答を整理します。

自プロジェクトに採用すべきか 次の条件に当てはまるなら、GoogleTest は有力な選択肢です。

• 外部依存の切り離しやモジュール間のインタラクション検証が必要で、モック機能を使いたい
• プロジェクトが C++17 以上を要求できる、または引き上げが現実的です
• 大規模・複数人開発で、xUnit 系の記述スタイルをチーム共通の型として揃えたい

逆に、次の場合は他の候補を先に検討する価値があります。

• テストのビルド時間が開発サイクルのボトルネックになっている → doctest
• C++14 以下に留める必要がある → Catch2 の v3 系・v2.x 系、または doctest
• BDD 的な記述で仕様を表現したい → Catch2
• すでに Boost に全面的に依存している → Boost.Test

類似リポジトリとどう違うか 最大の差分は GoogleMock の同梱です。Catch2・doctest はテストランナーとアサーションに責務を絞る設計で、モックは外部ライブラリとの組み合わせになります。加えて、要求 C++ 規格（GoogleTest は C++17 以上、Catch2 v3 系は C++14 以上、doctest は C++11 以上）と導入形態（GoogleTest はビルドしてリンク、doctest は単一ヘッダ）が実務上の違いとして効いてきます。

メンテナンス状況は健全か アーカイブもフォークもされていない現役リポジトリで、最終 push は 2026 年 9 月 1 日です。タグ付きリリースは年 1〜2 回のペースですが、Google の Foundational C++ Support Policy に紐づいたサポート範囲が公開されており、対応コンパイラの予測可能性は高いといえます。ライセンスは BSD-3-Clause で商用利用に支障はありません。注意点としては、v1.18.x ブランチが新機能パッチを受け付けず最新コミットからのビルドが推奨されていること、Abseil への依存追加が計画として告知されていることの 2 点があります。

次のアクションとしては、まず自プロジェクトが要求できる C++ 規格を確認し、モック検証の必要性を判定するところから始めるのが効率的です。GoogleTest を選ぶ場合は、公式の Quickstart: Building with CMake の最小構成をそのまま出発点にできます。

関連情報

C++ プロダクトのテスト基盤整備や既存システムの品質改善について、体制づくりの段階からご相談いただけます。ご検討中の方は お問い合わせフォーム からご連絡ください。