need a way to reset/clear expectations without verifying them

[GoogleCodeExporter]

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]

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:

• gmock-clear_expectations.patch

[GoogleCodeExporter]

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]

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:

• gmock-clear_expectations-1.7.0.patch