Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Deprecate InjectMocks
See original GitHub issueI think no one of the core team is a fan of this feature. The implementation is not as full-fletched as other dependency injection mechanisms. At the time of writing this issue, there are 17 open issues describing various problems with @InjectMocks. Moreover, as it solves a problem unrelated to mocking and there are different tools available to solve this use case, I propose we deprecate @InjectMocks and schedule for removal in Mockito 3/4. (I think 4 is best, to keep 3 a minimal breaking change version to ease upgrades).
Issue Analytics
- State:
- Created 5 years ago
- Reactions:9
- Comments:9 (7 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Did you receive any feedback @mockitoguy ?
It is a useful feature that has limitations we are not interested in addressing. Perhaps we should work on better error reporting / early failure when InjectMocks hits one of the limitations?
Do we aspire to build a “perfect” tool? We want to build a useful tool, that is “great enough”. In many other parts of our API we have caveats, typically caused by Java limitations. We always optimized to make the 95% case experience great, and remaining 5% decent (or not horrible 😉 - via good error messages, great documentation. Given Mockito popularity, this strategy has worked out.
Does removing this feature make Mockito better? I have a talk about Mockito 3 at CodeOne next week. I’ll ask the audience about InjectMocks.
Nice discussion! Thank you everybody for chiming in!