need a way to reset/clear expectations without verifying them
Closed this issue · 3 comments
GoogleCodeExporter commented
James Aguilar:
I have a test where I have some default expectations, some of which might be
overridden by some test cases. Is there a way to clear the default expectations
without verifying them?
Zhanyong:
There isn't a way to do that, as no one had asked for it before. What
you want to do sounds reasonable to me. We can add
ClearExpectations() and Clear() to testing::Mock (similar to
VerifyAndClearExpectations() and VerifyAndClear()).
Original issue reported on code.google.com by w...@google.com on 28 Oct 2010 at 4:44
GoogleCodeExporter commented
I have a simple patch against the 1.6.0 source code.
I haven't added any associated unit tests but if it looks useful feel free to
use it include it/modify it etc.
Original comment by Radics.A...@ansaldo-sts.com.au on 10 Feb 2012 at 6:07
Attachments:
GoogleCodeExporter commented
It turns out that it's not so easy to clear expectations and have the code
behave in an intuitive way. Assume we add the following method to
::testing::Mock
void Mock::ClearExpectations(void* mock);
What do we want this function to do when some of the mock object's methods have
been called? What if there are ordered expectations involving this and another
mock? e.g.
Expectation e1 = EXPECT_CALL(mock_foo, X());
EXPECT_CALL(mock_bar, Y()).After(e1);
Mock::ClearExpectations(&mock_foo);
// Now should this fail because it doesn't occur after a call to mock_foo.X(),
// or should we automatically ignore the After(e1) clause as e1 has been
// cleared? Either way we'll confuse some people.
mock_bar.Y();
If we add this, it will open door to many tests that are very hard to reason
about, as no one will be able to accurately understand the complex rules.
Note that VerifyAndClearExpectations() doesn't have this problem:
Expectation e1 = EXPECT_CALL(mock_foo, X());
EXPECT_CALL(mock_bar, Y()).After(e1);
Mock::VerifyClearExpectations(&mock_foo); // fails as e1 isn't satisfied.
// It doesn't matter whether this succeeds now, as the test was already failing!
mock_bar.Y();
===
For these reasons, I'm going to close this bug as WontFix because it's not
clear that the benefit is worth the added complexity.
Original comment by j...@google.com on 16 Nov 2012 at 7:35
- Changed state: WontFix
GoogleCodeExporter commented
I find the previously-submitted patch really useful because it allows me to
steer death tests down rainy day code paths that would be very difficult to
test with 'real' objects. For these kinds of tests, I don't care so much about
verification, I just want a programmable object that will force seldom-visited
branches of my code to be exercised. With this patch, I can call Mock::Clear()
at the end of a test to say: "Look, I already proved that the sequence of calls
I programmed exits, and that's all I care about. Please don't bother trying to
verify the mock's expectations."
I'm attaching a version of the patch updated for gmock-1.7.0, in case its
useful. I'd be *very* interested to hear whether there's some other way of
getting death tests and mocks to play nice together without this patch. This
link:
- http://stackoverflow.com/questions/20974251/wrong-function-calls-evaluation-when-in-death-test
makes it sound like patching gmock is the only solution, but maybe there are
other ways of achieving the same thing?
Original comment by evadef...@gmail.com on 12 May 2014 at 11:04
Attachments: