docs/development/languages/c-cpp/library_restrictions.md

# Library restrictions

## third_party/abseil-cpp

Decision: **do not use** `absl` in new code. Generally, `absl` is a
poor fit for use cases in Fuchsia. We will remove `absl` from the tree
once existing clients of it are migrated away. This removal work is tracked in
[https://fxbug.dev/42137495](https://fxbug.dev/42137495).

## third_party/googletest

Note: The googletest library includes both the former gtest and gmock
projects.

### Gtest

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

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`).

Pros:

  * 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.

Cons:

  * 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`).