Can't attach extra information to EXPECT_CALL

[MovEaxEsp]

All the standard gtest EXPECT and ASSERT macros support at least 2 ways (that I know of) for attaching arbitrary information to their output to provide context in case of failure (<< at the end, or ScopedTrace).

EXPECT_CALL, however, doesn't support either of these mechanisms. I haven't found any way of including any extra information in an EXPECT_CALL (or ON_CALL I suppose), which makes it impossible to debug EXPECT_CALLs in subroutines as described in https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#using-assertions-in-sub-routines

I hacked something for myself quite easily here, for the interested: https://github.com/MovEaxEsp/googletest/commit/a32b47d7467110a7fa6a5064ca339381ffc7bcdc

Ideally, EXPECT_CALL would include any active ScopedTraces at the time it's invoked, and include them in any failure output, and/or support << streaming so you could do:

EXPECT_CALL(...).WillOnce(...).RetireOnSaturation() << "my extra info";

but both of these might involve some work.

[asoffer]

Apologies for the delay.

SCOPED_TRACE doesn't make sense because EXPECT_CALL expectations live beyond the scope until the mock is destroyed. With this in mind, two options are:

1. Have your mocks destructor print the information you care about
2. Put the SCOPED_TRACE immediately after the construction of the mock?

But I think knowing the type of information you'd like to include would be useful here.

[pgrzech1]

Thanks for taking a look. Currently, the only thing I use this for is to stick the line number passed in from the caller of the subroutine that actually does the EXPECT_CALL, exactly as was described in #2732, but I'd hate for whatever solution is implemented for this to be limited to line numbers, and not be as general as whatever's available for other EXPECT_* or ASSERT_* macros.

With respect to the two options, they both seem to suggest sticking more information in the mock itself, which isn't what's being asked for here. What I'm looking for is extra context information to be stored with each individual expectation, so it can be printed whenever gmock has to print something about the expectation.

As an example, with #2689 , I modified the gmock output to look like:

../../src/groups/rgw/rgwr/rgwr_router.g.cpp:282: EXPECT_CALL(*d_terminals[terminal], sendMessageToTerminal(toExpect, BlobEq(payload))) with [line: 448]...
  Expected arg #0: is equal to [ type = TMGR sessionNumber = 0 window = 0 ]
           Actual: [ type = DISCONNECTED sessionNumber = 0 window = 0 ]
         Expected: to be called once
           Actual: never called - unsatisfied and active

(Notice the 'with [line: 448]' at the end of the first line).

Since creating that PR, I've found at least one location where an expectation might be printed that I missed, but this illustrates what I'd like to see modified in the output.

Finally, you mentioned that SCOPED_TRACE wouldn't work because the expectations outlive the SCOPED_TRACEs. I don't see that being an issue if the SCOPED_TRACEs are evaluated at the time the EXPECT_CALL is made, and the result is then just stored in the Expectation as a string.

[asoffer]

If you want something to happen on each call, perhaps it should be part of the expectation?

EXPECT_CALL(...).WillOnce(DoAll(ExtraLogging(), ActualMockLogic()));

Does this cover the main use cases?

[pgrzech1]

No, since if gmock has to print that the expectation was never met, because the mock function was never called, there'd be no information printed about where the EXPECT_CALL was made that setup the expectation that wasn't met. The idea is to modify that expectation description string that gmock itself prints to identify the expectation with extra information that will be printed independent of any actual call to the mock function.

[asoffer]

Thanks, and apologies again for the prolonged back-and-forth. This is not something we would like to support. Our strong preference is for mocks to be set at the beginning of a test without surrounding conditional or iterative logic. Adding such a facility makes it easier to write tests that require such logic.

[pgrzech1]

Interesting rationale, but very well. Thanks for the consideration.