Relevant: I just learned that microsoft/STL actually uses LLVM’s lit under the hood. A lead maintainer (also called STL) seems to like it.
From the STL README:
We rely on three test suites: std, tr1, and libcxx. We’ve partially ported std and tr1, and fully ported libcxx to run under lit using the various configurations/compilers we test internally.
Also called STL
Besides being an awesome individual, he has an amazing set of initials for a standard library developer lol. See also: Stephan T. Lavavej - MSFT, Author at C++ Team Blog
Also, moderator of /r/cpp where I think we both learned this. Although I think Louis Dionne mentioned that all implementations use the llvm test suite - plus their own of course.
I think @dsankel wrote a paper about lit for beman, see this thread:
David’s conclusion was:
Conclusion
We’ve investigated making lit the recommended Beman testing framework. Unlike other frameworks it has support for compilation failure tests, but it has several drawbacks including lack of popularity, complexity, and ergonomics challenges. Our recommendation is to instead adopt a more popular framework, such as GTest, and supplement it with CMake functions that add compilation failure capabilities.
Many people don’t like gtest because it is not header-only. But relatively recently catch2 stopped being header only. Just thought I would mention it.
Now here’s my two pennysworth…
I am a fan of gtest. There, I’ve said it.
I understand that beman wants to minimise dependencies so maybe beman needs to try and standardize a unit test framework. For full power, mocking might be considered a part of that. It would be a big project, to be sure, but what a foundation it would provide for the rest of beman.
Hi @marlowa – welcome! I think the main reason we’re still discussing is that on thing that’s clear is that gtest, for a variety of reasons, won’t be used by standard library vendors. So for easy adoption we’d like something that would be at least easily convertible to the frameworks used by vendors. It’s been pointed out that if they could use our test suites that would save them an enormous amount of development – even if they re-implement from scratch. All that said if the gtest usage stays relatively simple the conversion won’t likely be that difficult.
Having our tests be directly usable by standard library vendors is not a Beman project goal. I’m perfectly fine with Beman projects using GTest.
Call it what you want, but it’s an opportunity to improve the ecosystem by making the job of the few people in the world that provide implementations easier. This of course was expressed by one of these people in 2024 at c++now which led to the long conversation about Lit, etc.
All that said, if people really want to use gtest that’s ok with me, I just personally don’t want to use it. In my view it’s wildly over-complicated for testing these sorts of components - meaning fundamental libraries that are targeting the standard. Also a big set of tests these days should be running in constant evaluation which basically uses static_assert for tests. So I’m against having it as the default, but that’s it.
Of course, maybe in 2025 it’s all moot mostly – feed some tests to an AI and it will probably convert them from one framework to another pretty easily…
It’s a worthy cause, no doubt, but I’m much more motivated to improve the jobs of millions by upping the quality of C++ standard libraries.
Of course, you could argue that the millions will have improved lives by getting access to C++ standard libraries sooner if we use a testing framework that the standard library implementors like, but, yeah, AI or something 
.
That is no true, see CMAKE_SKIP_TEST_ALL_DEPENDENCY
the second you’re ready for a stub, fake, mock, or something like that, you’re pulling in googletest and googlemock anyway. So the question to answer to displace googletest is “if I’m pulling in googlemock anyway, why wouldn’t I just use googletest?”.
For what it is worth, and this thread hasn’t been active for several months, there is rollbear/trompeloeil for mocking specifically which interoperates with testing frameworks other than just googletest pretty well. It is in some ways nicer than googlemock IMO.
(Not sure where bemanproject has landed on testing overall with a prescriptive recommendation or not. I see that exemplar uses gtest)
I think we are at supporting gtest and catch2 out of the box in creating a new project. I don’t think we have a formal position on what testing framework, just on how the project behaves when integrating with other projects, where you don’t want to default to inflicting your tests and examples on the consumer.
We are relying a lot on the professionalism of implementors, so we don’t have rules about tests, coverage, and so on, just trying to provide support on the assumption that anyone wants it all, it’s just too much work.
Similarly for negative testing, important for std track code. I think I have some patterns, but it is very much a ton of work to make sure things fail for the right reason, and checking that against any matrix of compilers.
Similarly for consteval testing. Critical for std track, as well as turning up a lot of UB, but there is no common framework yet. And every if constexpr is a challenge, especially since constexpr doesn’t report coverage.