New strict stubbing API - MockitoSession #865
I'm with you on being very cautious about introducing features without user feedback or request. I think that this exactly the approach the core team should have to build a great library.
Thing is that in this situation there are users needing it. For example, I'm frustrated that myself and other engineers at LinkedIn cannot use strict stubbing (most of the tests use TestNG, there are also usages of custom runners).
In general, if the team chooses to implement a feature such us strict stubbing, then we should make the usage of the feature easy and flexible. We should not lock in users with JUnit. For example, Mockito has "@mock" annotation and offers flexible way of using that annotation: with JUnit Rule, Runner and without them (initMocks() method).
Also keep in mind that the new API is "@Incubating" so we could potentially take it away if we don't find it valuable.
I just rebased and bumped minor version to 2.7.0. This code is ready for final review and merge. I don't plan to work on the code unless there is more feedback.
The remaining unfinished action item in the description is a non-code change and does not block the review / merge.
- Changed the public API to MockitoSession per our discussion at #857. - MockitoSession offers meaningful name and semantics as opposed to somewhat cryptic MockitoMocking interface - New builder style interface for constructing session instances Pending - lots of javadoc (TODOs in code) - coverage for builder edge cases (e.g. when someone does not provide strictness or init mocks, etc.)
- Documented new public API methods. More documentation is pending. - Ensured predictable behavior for non-happy path. When 'null' values are configured, the builder will use sensible defaults. - Set the default strictness to be "strict stubs" so that users can take advantage for cleaner tests and better productivity by default.
1. Work still in progress 2. Mockito Strictness spans currently multiple classes and it's not easy to document it cohesively. Following types need to be reviewed for consistency: - UnnecessaryStubbingException - PotentialStubbingProblem - MockitoJUnitRunner and subclasses - MockitoSession - MockitoRule - Strictness