Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
New strict stubbing API - MockitoSession #865
See proposed design at #857
The code is reviewable, especially new public API. Please give feedback! More work is pending.
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.
- added comprehensive documentation for new MockitoSession API - mentioned new API from existing relevant methods (runner, the rule, mockito annotations)
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
Replaced package-local fields with setter and getter for clarity. Indeed it looks better because after all I needed only 2 out of 4 setter/getter methods and the public footprint of the class is smaller. Thank you for the suggestion!
Main documentation in the Mockito class links to MockitoSession from the paragraph that describes strictness. This way the main documentation is complete and describes the entire Mockito API.
Improved the documentation, exception message and tests wrt unfinished mocking session scenario.
- added coverage demonstrating that mockito session can be used concurrently, so long single thread has single active mockito session - tidied up the existing test: removed sys out println, fixed the naming issue