Trying to make it more clear: this is probably not about mock classes, but about mocked classes

PiperOrigin-RevId: 439427291
Change-Id: I3cac035e732fb3fe4f9c314657932a55269e0416
This commit is contained in:
Abseil Team 2022-04-04 15:30:21 -07:00 committed by Copybara-Service
parent 137f67e91f
commit c9044ba3dd

View File

@ -190,12 +190,12 @@ Some people put it in a `_test.cc`. This is fine when the interface being mocked
`Foo` changes it, your test could break. (You can't really expect `Foo`'s `Foo` changes it, your test could break. (You can't really expect `Foo`'s
maintainer to fix every test that uses `Foo`, can you?) maintainer to fix every test that uses `Foo`, can you?)
Generally, you should not define mock classes you don't own. If you must mock Generally, you should not mock classes you don't own. If you must mock such a
such a class owned by others, define the mock class in `Foo`'s Bazel package class owned by others, define the mock class in `Foo`'s Bazel package (usually
(usually the same directory or a `testing` sub-directory), and put it in a `.h` the same directory or a `testing` sub-directory), and put it in a `.h` and a
and a `cc_library` with `testonly=True`. Then everyone can reference them from `cc_library` with `testonly=True`. Then everyone can reference them from their
their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and
change, and only tests that depend on the changed methods need to be fixed. only tests that depend on the changed methods need to be fixed.
Another way to do it: you can introduce a thin layer `FooAdaptor` on top of Another way to do it: you can introduce a thin layer `FooAdaptor` on top of
`Foo` and code to this new interface. Since you own `FooAdaptor`, you can absorb `Foo` and code to this new interface. Since you own `FooAdaptor`, you can absorb