eson/googletest
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fix typos too s/destoyed/destroyed/

Browse Source
This commit is contained in:
Carlos O'Ryan 2017-07-01 15:26:42 -04:00
parent 280b22708c
commit 1dde1eed38
3 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
googlemock/docs/v1_5/CookBook.md
View File

@ -2081,12 +2081,12 @@ versus
## Forcing a Verification ## ## Forcing a Verification ##
When it's being destoyed, your friendly mock object will automatically When it's being destroyed, your friendly mock object will automatically
verify that all expectations on it have been satisfied, and will verify that all expectations on it have been satisfied, and will
generate [Google Test](http://code.google.com/p/googletest/) failures generate [Google Test](http://code.google.com/p/googletest/) failures
if not. This is convenient as it leaves you with one less thing to if not. This is convenient as it leaves you with one less thing to
worry about. That is, unless you are not sure if your mock object will worry about. That is, unless you are not sure if your mock object will
be destoyed. be destroyed.
How could it be that your mock object won't eventually be destroyed? How could it be that your mock object won't eventually be destroyed?
Well, it might be created on the heap and owned by the code you are Well, it might be created on the heap and owned by the code you are

4
googlemock/docs/v1_6/CookBook.md
View File

@ -2212,12 +2212,12 @@ MockFoo::~MockFoo() {}
## Forcing a Verification ## ## Forcing a Verification ##
When it's being destoyed, your friendly mock object will automatically When it's being destroyed, your friendly mock object will automatically
verify that all expectations on it have been satisfied, and will verify that all expectations on it have been satisfied, and will
generate [Google Test](http://code.google.com/p/googletest/) failures generate [Google Test](http://code.google.com/p/googletest/) failures
if not. This is convenient as it leaves you with one less thing to if not. This is convenient as it leaves you with one less thing to
worry about. That is, unless you are not sure if your mock object will worry about. That is, unless you are not sure if your mock object will
be destoyed. be destroyed.
How could it be that your mock object won't eventually be destroyed? How could it be that your mock object won't eventually be destroyed?
Well, it might be created on the heap and owned by the code you are Well, it might be created on the heap and owned by the code you are

4
googlemock/docs/v1_7/CookBook.md
View File

@ -2240,12 +2240,12 @@ MockFoo::~MockFoo() {}
## Forcing a Verification ## ## Forcing a Verification ##
When it's being destoyed, your friendly mock object will automatically When it's being destroyed, your friendly mock object will automatically
verify that all expectations on it have been satisfied, and will verify that all expectations on it have been satisfied, and will
generate [Google Test](http://code.google.com/p/googletest/) failures generate [Google Test](http://code.google.com/p/googletest/) failures
if not. This is convenient as it leaves you with one less thing to if not. This is convenient as it leaves you with one less thing to
worry about. That is, unless you are not sure if your mock object will worry about. That is, unless you are not sure if your mock object will
be destoyed. be destroyed.
How could it be that your mock object won't eventually be destroyed? How could it be that your mock object won't eventually be destroyed?
Well, it might be created on the heap and owned by the code you are Well, it might be created on the heap and owned by the code you are