Fixes #2399 : Adds defaultAnswer to the MockitoMockKey to distinguish the mock types, i.e. to separate mocks from spies otherwise spy type is reused for a mock or vice versa.

[vyazelenko]

Checklist

• Read the contributing guide
• PR should be motivated, i.e. what does it fix, why, and if relevant how
• If possible / relevant include an example in the description, that could help all readers
  including project members to get a better picture of the change
• Avoid other runtime dependencies
• Meaningful commit history ; intention is important please rebase your commit history so that each
  commit is meaningful and help the people that will explore a change in 2 years
• The pull request follows coding style
• Mention Fixes #<issue number> in the description if relevant
• At least one commit should mention Fixes #<issue number> if relevant

[TimvdLippe]

Nice find, fix and tests! 🎉

[TimvdLippe]

Ah, you will need to run ./gradlew spotlessApply locally to fix the formatting issues.

[vyazelenko]

@TimvdLippe Pushed formatting fixes.

[raphw]

That's a bad patch, I'm afraid. Answer is an interface and most instances do not implement hashCode/equals, this effectively breaks the caching mechanism what can cause significant overhead. The problem is the fix for #2331 which we must roll back. Mocks and spies classes must not consider the default answer when created classes. This must be solved on the interceptor level. I see what I can do but generally, we should not have allowed for the exception on the object methods.

I also see that this created an inconsistency for the inline and subclass mock makers. I am not entirely sure why this restriction was ever introduced in Mockito, but if we want to remove it, we would need to remove it generally, not for spies only.

[TimvdLippe]

Oof, that's definitely on me for not fully understanding the domain space. Thanks Rafael for the additional knowledge, that was not something I was aware of. Reverting all the fixes seems like the right course of action at this point in time, to avoid further snowballing.

I still think the intent of #2331 is good (it caught numerous bad tests at Google), so I would like to figure out an alternative solution that does not have the downsides of the existing implementation.