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