Update MockSettings usage

[jselbo]

• Remove @Incubating from useConstructor and outerInstance params. mockito-core removed @Incubating from these methods on MockSettings in the 4.0.0 release: mockito/mockito@7032574
• Remove lenient param since it is deprecated in MockitoSettings in mockito-core in favor of strictness
• Deprecate lenient param since it is deprecated in MockitoSettings in mockito-core
• Add new strictness param
• Add support for defaultAnswer setting for mockStatic API

[TimvdLippe]

I am fine with cleaning things up, but isn't the lenient change a breaking change? I am surprised none of our tests started failing. Maybe we lack test coverage for it?

[jselbo]

Yeah. Let me break each of these into separate PRs.
Actually that would lead to merge conflicts so I think easier to keep together.

Removal of lenient is a breaking change - yes, I guess we didn't have test coverage for it.

Let me add some test coverage for the new strictness param

[TimvdLippe]

We can also keep the lenient boolean, mark it as deprecated and then convert it to the correct strictness value. And if somebody supplies both, the strictness value takes precedence.

[jselbo]

Unfortunately Kotlin's @Deprecated annotation cannot be used on parameters, only on the entire method.

I'm not keen on introducing another mock overload, though that seems to be the only way to avoid the breaking change. What do you think?

[TimvdLippe]

I am confused, since I thought that we wouldn't need a mock overload given that they are all nullable? E.g. why wouldn't this work:

inline fun <reified T : Any> mock(
    extraInterfaces: Array<out KClass<out Any>>? = null,
    name: String? = null,
    spiedInstance: Any? = null,
    defaultAnswer: Answer<Any>? = null,
    serializable: Boolean = false,
    serializableMode: SerializableMode? = null,
    verboseLogging: Boolean = false,
    invocationListeners: Array<InvocationListener>? = null,
    stubOnly: Boolean = false,
    useConstructor: UseConstructor? = null,
    outerInstance: Any? = null,
    lenient: Boolean = false
    strictness: Strictness? = null,
): T {

As I understand it, this is backwards compatible as well, since we only add a new parameter and we keep the existing ones.

Sure, we can't mark the one parameter as deprecated, but we can denote that in the method description. And we can add that to a migration guide when we a publish a new major version.

[jselbo]

I see - yes that would work. I was thinking of marking the mock(..., lenient) method with @Deprecated but what you suggested is fine.

[m-koops]

I agree with your approach, Tim. Additionally, we can log a deprecation warning with Mockito logger when we detect lenient to be set to true.

Last bit, make the default value of the new strictness parameter follow the existing lenient setting:

inline fun <reified T : Any> mock(
    extraInterfaces: Array<out KClass<out Any>>? = null,
    name: String? = null,
    spiedInstance: Any? = null,
    defaultAnswer: Answer<Any>? = null,
    serializable: Boolean = false,
    serializableMode: SerializableMode? = null,
    verboseLogging: Boolean = false,
    invocationListeners: Array<InvocationListener>? = null,
    stubOnly: Boolean = false,
    useConstructor: UseConstructor? = null,
    outerInstance: Any? = null,
    lenient: Boolean = false,
    strictness: Strictness? = if (lenient) Strictness.LENIENT else null
): T {

This way, the implementation of the function can already rely on the value of the new strictness parameter, without breaking any current usages with lenient = true.