[Discussion] Patterns for integrating GoogleTest with C++20 Modules: Current state and future adoption?

[minhumanaisa]

​Context:
As C++20 adoption grows, many teams (including mine) are starting to migrate legacy headers to Modules. However, integrating this with established testing frameworks like GoogleTest presents unique challenges regarding build system support (CMake/Bazel) and visibility of internal interfaces for white-box testing.

​The Problem/Observation:
Currently, most documentation focuses on traditional header inclusion. When moving to modules, we face friction in:
​Exporting testable interfaces without polluting the public API.

​Interaction between gMock macros and module boundaries.

​Points for Discussion:
I would love to hear from the maintainers and the community on:
​Are there recommended patterns for "friend" access in a modularized world to allow GTest access to private implementation details?

​Has anyone successfully benchmarked the compile-time improvements of Modularized GTests vs Standard Headers?

​Looking forward to hearing your insights on how to future-proof our test suites.

[aliahmadnawawi]

​Context: As C++20 adoption grows, many teams (including mine) are starting to migrate legacy headers to Modules. However, integrating this with established testing frameworks like GoogleTest presents unique challenges regarding build system support (CMake/Bazel) and visibility of internal interfaces for white-box testing.

​The Problem/Observation: Currently, most documentation focuses on traditional header inclusion. When moving to modules, we face friction in:​Exporting testable interfaces without polluting the public API.

​Interaction between gMock macros and module boundaries.

​Points for Discussion: I would love to hear from the maintainers and the community on:​Are there recommended patterns for "friend" access in a modularized world to allow GTest access to private implementation details?

​Has anyone successfully benchmarked the compile-time improvements of Modularized GTests vs Standard Headers?

​Looking forward to hearing your insights on how to future-proof our test suites.

​Hi there,

​We are facing similar challenges in our migration to C++20 Modules. It definitely feels like we are in the "early adopter" phase where tooling (CMake/Bazel) and frameworks are playing catch-up.

​Regarding the points you raised, here are a few patterns and observations we’ve looked into:

​1. Patterns for "Friend" Access (White-Box Testing)

​The strict visibility rules of Modules make the traditional FRIEND_TEST macro usage tricky. Since non-exported symbols are invisible to importers, simply "friending" a test class isn't enough if the test class can't even see the type it's trying to test.

​Two patterns have shown promise:
​The "Attorney-Client" Idiom (adapted for Modules):
Instead of friending specific GTest test cases (which is brittle with name mangling and namespaces), we export a special TestingAccess class (the "Attorney") in a module:private or strictly internal partition. This class creates a "bridge" to the internal types. The test suite imports the module and uses this exported bridge to access internals. It requires a bit of boilerplate but keeps the public API clean for actual users while exposing hooks for tests.

​Module Partitions for Tests:
If your build system supports it, defining your tests within a module implementation partition (e.g., module MyModule:Tests) allows them full access to the module's internals without needing export. The downside is that this couples your tests strictly to the module structure and can complicate build graphs, but it is the most "native" C++20 way to handle white-box testing.

​2. Benchmarks (Modularized GTest vs. Headers)

​We haven't seen a massive compile-time drop for clean builds yet, mostly because GTest itself is heavily templated and usually included via headers (even if wrapped in a module). The biggest gains we've observed are in incremental build times.

​Observation: Touching a private implementation partition triggers significantly fewer recompilations compared to touching a private header that was transitively included everywhere.

​Caveat: Until GoogleTest itself is fully modularized (providing a clean .bmi/.pcm), we are still paying the cost of parsing GTest headers in every test translation unit.

​3. Future-Proofing

​For future-proofing, we are trying to shift our philosophy slightly:
​Bias toward Black-Box: Modules encourage strong encapsulation. We are treating this as a push to test strictly through the exported public interface whenever possible.

​Separate "Testable" Interface: For complex logic that must be white-box tested, we are moving that logic into its own smaller, fully exported module (or library) that the main module consumes. This makes the logic public-to-the-test but private-to-the-application structure.

​Would love to hear if others have managed to get FRIEND_TEST working seamlessly across module boundaries without using the "Attorney" pattern!

[minhumanaisa]

Oke thx u bro!