From d81ae2f0bf2bb3fbb23691cae68e75a7563ae19d Mon Sep 17 00:00:00 2001 From: Abseil Team Date: Wed, 22 Dec 2021 22:49:37 -0800 Subject: [PATCH] Clarify "package" means "Bazel package", and promote `testonly=True` rather than `testing` sub-directory. PiperOrigin-RevId: 417945818 Change-Id: I8686ee0414fb80269528677f291877a231d1c991 --- docs/gmock_for_dummies.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/gmock_for_dummies.md b/docs/gmock_for_dummies.md index 0392b5de..fa1296ee 100644 --- a/docs/gmock_for_dummies.md +++ b/docs/gmock_for_dummies.md @@ -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 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, -define the mock class in `Foo`'s package (better, in a `testing` sub-package -such that you can clearly separate production code and testing utilities), put -it in a `.h` and a `cc_library`. Then everyone can reference them from their -tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and -only tests that depend on the changed methods need to be fixed. +Generally, you should not define mock classes you don't own. If you must mock +such a class owned by others, define the mock class in `Foo`'s Bazel package +(usually the same directory or a `testing` sub-directory), and put it in a `.h` +and a `cc_library` with `testonly=True`. Then everyone can reference them from +their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to +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 `Foo` and code to this new interface. Since you own `FooAdaptor`, you can absorb