fix: #2656

Release 4.6.0 introduced a new feature #2650 to allow strictness to be set via the @Mock annotation. Unfortunately, the feature has a bug that results in any test-level strictness setting being ignored, e.g.

@ExtendWith(MockitorExtension.class)
@MockitoSettings(strictness = Strictness.LENIENT)
class ThingTest {

  @Mock
  private Thing lenientMock;
}

In the above code the lenientMock would actually be strict, as the @Mock's strictness defaults to STRICT_STUBS. This default was overriding the test level LENIENT.

To fix the issue the default of the Mock.strictness method needs to be something meaning not set, allowing the mock's strictness to be ignored and the test level strictness to be used.

Unfortunately, no no set value exists in the Strictness enum and it is illegal to default to null. Fixing this in a backwards compatible way would have meant polluting the public API, (e.g. adding a DEFAULT value to the existing Strictness enum, which doesn't make sense in a lot of other places the enum is used). As this feature has only just been released, and is essentially broken, a breaking change is being introduced to fix the issue.

BREAKING CHANGE: This PR changes the return value of Mock.strictness() to a local Strictness enum value. This will require users to change any code written against 4.6.0 that sets the strictness via the @Mock annotation to change their code.

Example code migration:

class ThingTest {

    @Mock(strictness = Strictness.LENIENT)
    private Thing thing;

    ...
}

To:

class ThingTest {

    @Mock(strictness = Mock.Strictness.LENIENT)
    private Thing thing;

    ...
}

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