-
Notifications
You must be signed in to change notification settings - Fork 10.6k
Description
Does the feature exist in the most recent commit?
No
Why do we need this feature?
Naggy mode is inappropriate for large projects because
- Most of the time people don't even see the warnings,
- Even if they do see the warnings, they have no idea whether they represent a real problem or not.
Large projects should never use naggy mock. Unfortunately, many people have strong opinions on which of NiceMock or StrictMock is the better default and no-one can agree, so just making one of those the default will not work.
Describe the proposal.
I propose to add a configurable preprocessor macro to GoogleMock to require choosing between StrictMock and NiceMock. Naggy mock mode would never be used if the macro was set to 1.
I also propose adding macros to mock classes that declare the default behaviour for that class:
DEFAULT_TO_STRICT();
DEFAULT_TO_NICE();
When GOOGLEMOCK_REQUIRE_STRICT_OR_NICE was set to 1, then a declaration like StrictMock<MockFoo> mock_foo or NiceMock<MockFoo> mock_foo would work as before, but just MockFoo mock_foo would fail to compile, unless you added one of those macros to the definition, like
class MockFoo : public Foo {
public:
DEFAULT_TO_STRICT();
MOCK_METHOD(void, DoFoo, (), (override));
};
This also provides an upgrade path for existing large projects. They can add a macro
#define TODO_CHOOSE_NICE_OR_STRICT() DEFAULT_TO_NICE()
and then do a mass rewrite to add TODO_CHOOSE_NICE_OR_STRICT() to every existing mock class before adding -DGOOGLEMOCK_REQUIRE_STRICT_OR_NICE=1 to the compiler command line.
There is a minor complication that subprojects would still have to be compiled without the macro set, which would complicate build files a bit, but I don't think it's an unsolvable problem. It does mean that it is important that the macro does not change the library ABI.
Is the feature specific to an operating system, compiler, or build system version?
Nope.