Google Git
Sign in
chromium/external/github.com/google/googletest.git/main
commit
d72f9c8aea6817cdf1ca0ac10887f328de7f3da2
[log] [tgz]
author
Dillon Sharlet <dsharlet@google.com>
Tue Mar 31 14:21:41 2026
committer
Copybara-Service <copybara-worker@google.com>
Tue Mar 31 14:22:05 2026
tree
73d2b80cb8ee41083f6e29c651cb2da7c9639211
parent
5fddfab2d22270b0b4608bbb20e4ebb65c22af24 [diff]
Add `--gtest_shard_index` and `--gtest_total_shards` command line arguments.

This uses the environment variables as the default value for the command line argument, so this is not a breaking change to most reasonable existing use cases. This *is* a breaking change if a process expects changes to the sharding environment variables to be visible after parsing the command line arguments.

The motivation for this is that some environments do not support environment variables, which prevents the usage of test sharding. These environments also run on simulators and other slow hardware, where sharding is especially important. I've tried a few other things, like hacking together a fake implementation of `getenv`/`setenv`, but this is a pretty unreliable approach on the platform in question.

This also seems like an improvement in consistency to me. Currently, other test selection mechanisms (e.g. filtering, shuffling, repeat), `use arguments (or at least have command line arguments as an option), while as far as I can tell, sharding is the only mechanism which can *only* be specified with environment variables.

PiperOrigin-RevId: 892324928
Change-Id: I5cf814e46e16072e7c160e54c426b02300fe712b
4 files changed
tree: 73d2b80cb8ee41083f6e29c651cb2da7c9639211
  1. .github/
  2. ci/
  3. docs/
  4. googlemock/
  5. googletest/
  6. .clang-format
  7. .gitignore
  8. BUILD.bazel
  9. CMakeLists.txt
  10. CONTRIBUTING.md
  11. CONTRIBUTORS
  12. fake_fuchsia_sdk.bzl
  13. googletest_deps.bzl
  14. LICENSE
  15. MODULE.bazel
  16. README.md
  17. WORKSPACE
  18. WORKSPACE.bzlmod
README.md

GoogleTest

Announcements

Documentation Updates

Our documentation is now live on GitHub Pages at https://google.github.io/googletest/. We recommend browsing the documentation on GitHub Pages rather than directly in the repository.

Release 1.17.0

Release 1.17.0 is now available.

The 1.17.x branch requires at least C++17.

Continuous Integration

We use Google's internal systems for continuous integration.

Coming Soon

  • We are planning to take a dependency on Abseil.

Welcome to GoogleTest, Google's C++ test framework!

This repository is a merger of the formerly separate GoogleTest and GoogleMock projects. These were so closely related that it makes sense to maintain and release them together.

Getting Started

See the GoogleTest User's Guide for documentation. We recommend starting with the GoogleTest Primer.

More information about building GoogleTest can be found at googletest/README.md.

Features

  • xUnit test framework:
    Googletest is based on the xUnit testing framework, a popular architecture for unit testing
  • Test discovery:
    Googletest automatically discovers and runs your tests, eliminating the need to manually register your tests
  • Rich set of assertions:
    Googletest provides a variety of assertions, such as equality, inequality, exceptions, and more, making it easy to test your code
  • User-defined assertions:
    You can define your own assertions with Googletest, making it simple to write tests that are specific to your code
  • Death tests:
    Googletest supports death tests, which verify that your code exits in a certain way, making it useful for testing error-handling code
  • Fatal and non-fatal failures:
    You can specify whether a test failure should be treated as fatal or non-fatal with Googletest, allowing tests to continue running even if a failure occurs
  • Value-parameterized tests:
    Googletest supports value-parameterized tests, which run multiple times with different input values, making it useful for testing functions that take different inputs
  • Type-parameterized tests:
    Googletest also supports type-parameterized tests, which run with different data types, making it useful for testing functions that work with different data types
  • Various options for running tests:
    Googletest provides many options for running tests including running individual tests, running tests in a specific order and running tests in parallel

Supported Platforms

GoogleTest follows Google's Foundational C++ Support Policy. See this table for a list of currently supported versions of compilers, platforms, and build tools.

Who Is Using GoogleTest?

In addition to many internal projects at Google, GoogleTest is also used by the following notable projects:

Related Open Source Projects

GTest Runner is a Qt5 based automated test-runner and Graphical User Interface with powerful features for Windows and Linux platforms.

GoogleTest UI is a test runner that runs your test binary, allows you to track its progress via a progress bar, and displays a list of test failures. Clicking on one shows failure text. GoogleTest UI is written in C#.

GTest TAP Listener is an event listener for GoogleTest that implements the TAP protocol for test result output. If your test runner understands TAP, you may find it useful.

gtest-parallel is a test runner that runs tests from your binary in parallel to provide significant speed-up.

GoogleTest Adapter is a VS Code extension allowing to view GoogleTest in a tree view and run/debug your tests.

C++ TestMate is a VS Code extension allowing to view GoogleTest in a tree view and run/debug your tests.

Cornichon is a small Gherkin DSL parser that generates stub code for GoogleTest.

Contributing Changes

Please read CONTRIBUTING.md for details on how to contribute to this project.

Happy testing!