Don't mock interface default methods

[chrylis]

I have an interface that has a default method overload that can transform an instance of any sort of bar (in this case, message format) into a canonical format for processing.

interface Foo {
  void doThing(SpecificType bar);

  default void doThing(SuperType bar) {
    doThing(new SpecificType(bar));
  }
}

I want to test that when I call Foo#doThing with a SomeOtherBar, the message gets correctly transformed and sent out the SpecificType overload. However, Spock's Mock() intercepts all methods, including default methods.

Since one main purpose of default methods is to support adaptation onto legacy APIs, this behavior will prevent backwards-compatibility bridges from working if a provider API is upgraded. Instead, it should be possible to either by default (my preference) or explicitly exclude default interface methods from being implemented by the mock proxy.

[szpak]

You could use a mechanism usually used in Spy() to instruct Spock to call a real method on the underlying object.

given:
    Foo foo = Mock()
    foo.doThingDefault(_) >> { callRealMethod() }

However, in the situation where both methods have the same name the syntax is more complicated as Spock takes the first stubbing for the same method name, even with a different input argument type. Therefore, you need to use something like:

given:
    Foo foo = Mock()
    foo.doThing(_) >> { it[0] instanceof String ? it[0] : callRealMethod() }

(to get know why you can't return just it, but it[0] you can check my presentation from Gr8Conf 2016 :) ).

It works fine with Spock 1.1 which migrated to ByteBuddy (I haven't tested it with cglib).

Btw, I'm not sure if it is worth to have an ability to disable mocking default methods globally.

[chrylis]

I'm aware of the "first stub" issue, and it feels like a bug (specifically, that it happens even if I explicitly say doThing(_ as SpecificType)). And I've been using Spock for a while and reflexively dance around the it semantics now. ;-)

Why would it not be worth it? The rule is unambiguous, default methods are easy to identify, and there are numerous instances, such as with the Collection types retrofit, where checking that the type under test Does The Right Thing when a default method does some sort of wrapping or delegation is immensely useful, especially for regression control where you start out using a general-purpose unoptimized default implementation and then later come back to add a custom one.

[chrylis]

This same bug bit me again today on Spock 1.2 for this exact case: The default method is a wrapper that does some useful conversion and delegates to the underlying. Mocking the underlying does no good because Spock wipes out the default method.

[chrylis]

And callRealMethod() doesn't work in 1.2. In fact, the situation is actually worse, because the documented default behavior for mock with a return type of Optional is empty, but a default method on a mocked interface returns null. Debugging, it appears that once you use callRealMethod, you have permanently exited the Spock mock system, and the attempt by the default method to self-call the underlying method that should be mocked results in "Cannot invoke real method in interface based mock object".

[szpak]

Optional.empty() is used by default only for stubs, not mocks.

@chrylis Could you send a complete specification (a test class) that reproduce the problem? Does that particular example work in Spock 1.1?

[chrylis]

I have a repro of the underlying concerns.

To summarize:

• Wiping out a default implementation in any test double that does not have a declared interaction violates the Rule of Least Surprise. I want to test that the subject makes the correct DB call, not whether it uses the default method to perform type conversion or does it inline (an implementation detail and the purpose of default methods).

• Every test double in Spock overwrites default methods.

• Neither Mock() nor Spy() can use callRealMethod() to explicitly re-delegate to the default method.

• Stub() can use callRealMethod() to the default method but then cannot make cardinality assertions on the test double, which severely reduces its usefulness.

Proposed behavior change in Spock: If an interface method is a default method, then Spock should simply do nothing (that is, let the default stand) unless it has an explicit interaction.

[mettyoung]

Any workaround here please?

[Vampire]

Workaround for what?

I don't see any issue here, and the feature request that was requested imho is not a good idea.

Speaking about the MCVE @chrylis provided:

• delegating to mocked method via default implementation succeeds with Mock
  of course fails as stubs and mocks by default mock each and every method, that is their job,
  so as no explicit stubbing was done, a mock always returns false here
• explicit callRealMethod() succeeds with Mock
  this would work if the intended mockWithExplicitRealCall would be used instead of the copy&paste error mock
  and additionally this chapter was not considered https://spockframework.org/spock/docs/2.4-M2/all_in_one.html#_combining_mocking_and_stubbing that describes that you cannot split stubbing and mocking for the same method but have to do it in the same interaction,
  so fixing the used property and adding >> true in the then line makes the test green
• delegating to mocked method via default implementation succeeds with Stub
  of course you cannot assert cardinality, that's the point of a stub, you just use it for stubbing responses
  if you want a mock with the response behavior of a stub, then use an a-la-carte mock where you create a mock with the default response set to the one used for stubs by default
  the ambitious defaults just mean that it returns "something" but not null where it can, not that it interprets whether a default method should be stubbed out by default or not because it just bridges to another method
• delegating to mocked method via default implementation succeeds with Spy
  same problem here as in the second bullet-point, you cannot split stubbing and mocking
  if you add >> true to the then, it works
• explicit callRealMethod() succeeds with Spy
  nothing escapes anywhere, just again the same problem as in the previous bullet-point
  if you add >> true to the then, it works

Speaking about the summary:

• "Wiping out a default implementation in any test double that does not have a declared interaction violates the Rule of Least Surprise."
  I'm totally on the opposite.
  Mocks and Stubs stub out each and every method.
  Default methods are not special here.
  If Default methods would not be stubbed out by default, that would for me violate "Rule of Least Surprise", as Mocks and Stubs are supposed to stub out each and every method.
• "I want to test that the subject makes the correct DB call, not whether it uses the default method to perform type conversion or does it inline (an implementation detail and the purpose of default methods)."
  What a default method does Spock can hardly guess and shouldn't.
  You could do all sorts of things in default methods.
  Doing such bridging code for legacy implementors is just one of the many possibilities for which default methods can be used.
• "Every test double in Spock overwrites default methods."
  Yes, that's their job.
  Well, except for Spy of course.
• "Neither Mock() nor Spy() can use callRealMethod() to explicitly re-delegate to the default method."
  Yes, they can.
• "Stub() can use callRealMethod() to the default method but then cannot make cardinality assertions on the test double, which severely reduces its usefulness."
  No, that's intentional, a Stub as its name suggests is only for stubbing, not for interaction based tests, for that you need a Mock, but as mentioned above, you can anytime also create a Mock with defaultResponse set to what Stub would use by default
• "Proposed behavior change in Spock: If an interface method is a default method, then Spock should simply do nothing (that is, let the default stand) unless it has an explicit interaction."
  I would consider such behavior a bug, and in such I'm going to close this issue as "not planned" unless some @spockframework/supporter or @spockframework/committers objects to this.

Besides that, if you really want such a behavior in your tests, you can easily use an own defaultResponse to do exactly what you ask for, for example using something like

class DefaultMethodPreserver implements IDefaultResponse {
    def delegate

   DefaultMethodPreserver(delegate) {
      this.delegate = delegate
   }

   @Override
   Object respond(IMockInvocation invocation) {
      if (invocation.mockObject.type.getMethod(invocation.method.name, *invocation.method.parameterTypes).default) {
          invocation.callRealMethod()
      } else {
          delegate.respond(invocation)
      }
   }
}

MockMe mock = Mock(defaultResponse: new DefaultMethodPreserver(ZeroOrNullResponse.INSTANCE)) {
    equalsOne(_ as UUID) >> { ONE == it[0] }
}

MockMe stub = Stub(defaultResponse: new DefaultMethodPreserver(EmptyOrDummyResponse.INSTANCE)) {
    equalsOne(_ as UUID) >> { ONE == it[0] }
}