Clarify "package" means "Bazel package", and promote testonly=True rather than testing sub-directory.

PiperOrigin-RevId: 417945818
Change-Id: I8686ee0414fb80269528677f291877a231d1c991
This commit is contained in:
Abseil Team 2021-12-22 22:49:37 -08:00 committed by Copybara-Service
parent c58f562fa2
commit d81ae2f0bf

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?)
So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, Generally, you should not define mock classes you don't own. If you must mock
define the mock class in `Foo`'s package (better, in a `testing` sub-package such a class owned by others, define the mock class in `Foo`'s Bazel package
such that you can clearly separate production code and testing utilities), put (usually the same directory or a `testing` sub-directory), and put it in a `.h`
it in a `.h` and a `cc_library`. Then everyone can reference them from their and a `cc_library` with `testonly=True`. Then everyone can reference them from
tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to
only tests that depend on the changed methods need to be fixed. change, and 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