Skip to content

Commit

Permalink
Trying to make it more clear: this is probably not about mock classes…
Browse files Browse the repository at this point in the history
…, but about mocked classes

PiperOrigin-RevId: 439427291
Change-Id: I3cac035e732fb3fe4f9c314657932a55269e0416
  • Loading branch information
Abseil Team authored and copybara-github committed Apr 4, 2022
1 parent 137f67e commit c9044ba
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions docs/gmock_for_dummies.md
Original file line number Diff line number Diff line change
Expand Up @@ -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?)

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.
Generally, you should not 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
Expand Down

0 comments on commit c9044ba

Please sign in to comment.