Google is committed to advancing racial equity for Black communities. See how.

Library restrictions


Decision: do not use <absl/synchronization/*>. On Fuchsia, these classes bottom out in pthread_mutex_t and pthread_cond_t, which are not the most efficient primitives on Fuchsia. When ABSL_INTERNAL_USE_NONPROD_MUTEX is defined, these primitives bottom out in something much more sophisticated. Instead, please use <lib/sync/*.h>, which bottoms out in optimal synchronization primitives on Fuchsia.



Use the Gtest framework for writing tests everywhere except the Zircon directory. It provides the TEST and TEST_F macros as well as the ASSERT and EXPECT variants we use.

Inside the Zircon directory, use system/ulib/zxtest instead. It provides a Gtest-like interface with fewer dependencies on higher-level OS concepts like mutexes (things we want to test). It also supports writing tests in C which is required for some layers.


Gmock has several components. We allow the gmock matchers such as ElementsAre().

There are varying opinions on the team on the function mocking functions (MOCK_METHOD and EXPECT_CALL).


  • It can be very efficient to do certain types of mocking.
  • Some people feel that Gmock-generated mocks are easier to read than the equivalent custom code.
  • Lack of a mocking library means some people might not write good tests.


  • Gmock provides a domain-specific language. Not everybody understands this language, and the complex use of templates and macros make it hard to diagnose problems.
  • Some aspects of Gmock encourage overly constrained mocks.
  • Combinations of the above can make it harder to make changes to mocked code later.

Decision: do not use the mocking functionality of gmock (MOCK_METHOD and EXPECT_CALL).