"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "docs/gmock_for_dummies.md" between
googletest-release-1.11.0.tar.gz and googletest-release-1.12.0.tar.gz

About: GoogleTest is Google's (unit) testing and mocking framework for C++ tests.

gmock_for_dummies.md  (googletest-release-1.11.0)	:	gmock_for_dummies.md  (googletest-release-1.12.0)
skipping to change at line 193		skipping to change at line 193
macro will generate the definitions for you. It's that simple!		macro will generate the definitions for you. It's that simple!
### Where to Put It		### Where to Put It
When you define a mock class, you need to decide where to put its definition.		When you define a mock class, you need to decide where to put its definition.
Some people put it in a `_test.cc`. This is fine when the interface being mocked		Some people put it in a `_test.cc`. This is fine when the interface being mocked
(say, `Foo`) is owned by the same person or team. Otherwise, when the owner of		(say, `Foo`) is owned by the same person or team. Otherwise, when the owner of
`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 mock classes you don't own. If you must mock such a
define the mock class in `Foo`'s package (better, in a `testing` sub-package		class owned by others, define the mock class in `Foo`'s Bazel package (usually
such that you can clearly separate production code and testing utilities), put		the same directory or a `testing` sub-directory), and put it in a `.h` and a
it in a `.h` and a `cc_library`. Then everyone can reference them from their		`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		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.		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
changes in `Foo` much more easily. While this is more work initially, carefully		changes in `Foo` much more easily. While this is more work initially, carefully
choosing the adaptor interface can make your code easier to write and more		choosing the adaptor interface can make your code easier to write and more
readable (a net win in the long run), as you can choose `FooAdaptor` to fit your		readable (a net win in the long run), as you can choose `FooAdaptor` to fit your
specific domain much better than `Foo` does.		specific domain much better than `Foo` does.
skipping to change at line 483		skipping to change at line 483
explicit `Times()`), will return 100 and 200 respectively the first two times,		explicit `Times()`), will return 100 and 200 respectively the first two times,
and 300 from the third time on.		and 300 from the third time on.
Of course, if you explicitly write a `Times()`, gMock will not try to infer the		Of course, if you explicitly write a `Times()`, gMock will not try to infer the
cardinality itself. What if the number you specified is larger than there are		cardinality itself. What if the number you specified is larger than there are
`WillOnce()` clauses? Well, after all `WillOnce()`s are used up, gMock will do		`WillOnce()` clauses? Well, after all `WillOnce()`s are used up, gMock will do
the *default* action for the function every time (unless, of course, you have a		the *default* action for the function every time (unless, of course, you have a
`WillRepeatedly()`.).		`WillRepeatedly()`.).
What can we do inside `WillOnce()` besides `Return()`? You can return a		What can we do inside `WillOnce()` besides `Return()`? You can return a
reference using `ReturnRef(*variable*)`, or invoke a pre-defined function, among		reference using `ReturnRef(`*`variable`*`)`, or invoke a pre-defined function,
[others](gmock_cook_book.md#using-actions).		among [others](gmock_cook_book.md#using-actions).
**Important note:** The `EXPECT_CALL()` statement evaluates the action clause		**Important note:** The `EXPECT_CALL()` statement evaluates the action clause
only once, even though the action may be performed many times. Therefore you		only once, even though the action may be performed many times. Therefore you
must be careful about side effects. The following may not do what you want:		must be careful about side effects. The following may not do what you want:
```cpp		```cpp
using ::testing::Return;		using ::testing::Return;
...		...
int n = 100;		int n = 100;
EXPECT_CALL(turtle, GetX())		EXPECT_CALL(turtle, GetX())
End of changes. 2 change blocks.
6 lines changed or deleted		6 lines changed or added

---