-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update mockito monorepo to v5 (major) #12501
Conversation
⚠ Artifact update problemRenovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is. ♻ Renovate will retry this branch, including artifacts, only when one of the following happens:
The artifact failure details are included below: File name: build.gradle
|
867e000
to
4516406
Compare
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
efc5cf9
to
5acbae6
Compare
6153ea2
to
1b4d7d4
Compare
1b4d7d4
to
3c521c1
Compare
c5113c4
to
408df76
Compare
408df76
to
38a352a
Compare
38a352a
to
6a26398
Compare
b535aaa
to
f006098
Compare
f006098
to
05f61c1
Compare
05f61c1
to
c9ab2e6
Compare
c9ab2e6
to
0f80855
Compare
9c66853
to
576bd96
Compare
8438fd6
to
a263a7a
Compare
a263a7a
to
705a4a3
Compare
705a4a3
to
0a54505
Compare
0a54505
to
aced9fa
Compare
aced9fa
to
96b11bb
Compare
APK file: https://www.kaminsky.me/nc-dev/android-artifacts/12501.apk |
58e2671
to
2a464da
Compare
Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Signed-off-by: Tobias Kaminsky <[email protected]>
2a464da
to
4bd41ed
Compare
test-Unit test failed: https://www.kaminsky.me/nc-dev/android-integrationTests/12501-Unit-test-18-58 |
This PR contains the following updates:
4.11.0
->5.14.1
4.11.0
->5.14.1
Release Notes
mockito/mockito (org.mockito:mockito-android)
v5.14.1
What's Changed
Full Changelog: mockito/mockito@v5.14.0...v5.14.1
v5.14.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.14.0
v5.13.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.13.0
Only.verify
throwsNullPointerException
(#3237)v5.12.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.12.0
AdditionalMatchers.and()
andAdditionalMatchers.or()
not to swap the order of matchers (#3335)v5.11.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.11.0
@Captor
test parameters don't work with primitive type arguments (#3229)v5.10.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.10.0
v5.9.0
What's Changed
New Contributors
Full Changelog: mockito/mockito@v5.8.0...v5.9.0
v5.8.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.8.0
v5.7.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.7.0
0.8.11
(#3147)v5.6.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.6.0
Optional
is notempty
when usingRETURN_DEEP_STUBS
(#2865)v5.5.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.5.0
v5.4.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.4.0
@Mock(serializable = true)
for parameterized types. (#3007)ArgumentMatchers#any()
JavaDoc(#3003)
@Mock(serializable = true)
no longer works with parameterized types (#2979)v5.3.1
Changelog generated by Shipkit Changelog Gradle Plugin
5.3.1
v5.3.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.3.0
withoutAnnotations
parameter to@Mock
(#2965)ArgumentMatchers#assertArg
method. (#2949)v5.2.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.2.0
v5.1.1
Changelog generated by Shipkit Changelog Gradle Plugin
5.1.1
v5.1.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.1.0
CONTRIBUTING.md
(#2870)CONTRIBUTING.md
(#2868)Mockito#{mock,spy}(T... reified)
with@SafeVarargs
(#2866)v5.0.0
Mockito 5: prepare for future JDK versions
For a while now, we have seen an increase in problems/incompatibilities with recent versions of the JDK due to our usage of JVM-internal API.
Most notably, JDK 17 made some changes which are incompatible with the current subclass mockmaker.
Therefore, to prepare for the future of JDK, we are making some core changes to ensure Mockito keeps on working.
Switch the default mockmaker to
mockito-inline
Back in Mockito 2.7.6, we published a new mockmaker based on the "inline bytecode" principle.
This mockmaker creates mocks manipulating bytecode equivalent within the original class such that its method implementations hook into the normal Mockito machinery.
As a comparison, the subclass mockmaker generates "real" subclasses for mocks, to mimic the same behavior.
While the approaches are similar, the inline mockmaker avoids certain restrictions that the JDK imposes.
For example, it does not violate module boundaries (introduced in JDK 9, but more heavily used in JDK 17) and avoids the leaking of the creation of the subclass.
Massive thanks to community member @reta who implemented this change.
Note: this does not affect
mockito-android
nor testing on Android.When should I still be using the subclass mockmaker?
There are legitimate remaining use cases for the subclass mockmaker.
For example, on the Graal VM's native image, the inline mockmaker will not work and the subclass mockmaker is the appropriate choice.
Additionally, if you would like to avoid mocking final classes, using the subclass mockmaker is a possibibility.
Note however that if you solely want to use the subclass mockmaker to avoid mocking final, you will run into the above mentioned issues on JDK 17+.
We want to leave this choice up to our users, which is why we will keep on supporting the subclass mockmaker.
If you want to use the subclass mockmaker instead, you can use the new
mockito-subclass
artifact (published on Maven Central along with all our other artifacts).Update the minimum supported Java version to 11
Mockito 4 supports Java 8 and above.
Similar to other open source projects, we are moving away from JDK 8 and to newer versions.
The primary reason for moving away from JDK 8 is the increasing maintenance costs with keeping our own infrastructure working.
Lately we have been running into more and more JDK 8 breakages.
Additionally, while we want to support the newest JDK API's, our current solution to support both JDK 8 and newer versions causes issues with the
SecurityManager
.Since we want Mockito to work on the newest version and more and more businesses adopting JDK 11, we have decided to make the switch as well.
Massive thanks to community member @reta who implemented this change.
What should I do if I still run JDK 8?
For JDK 8 and below, you can keep on using Mockito 4.
This is similar to if you are using JDK 6, for which you can keep on using Mockito 2.
The changes in Mockito 5 (for now) are primarily focused on the latest JDK versions, which means the API differences between Mockito 4 and 5 are minimal.
However, over time this will most likely widen, so we do recommend adopting JDK 11 in the future.
New
type()
method onArgumentMatcher
One of our most used public API's for customizing Mockito is the
ArgumentMatcher
interface.The interface allows you to define a custom matcher, which you can pass into method arguments to provide more targeted matches.
One major shortcoming of the
ArgumentMatcher
was the lack of varargs support.There were many, many issues filed related to varargs and Mockito unable to handle them.
Community member @big-andy-coates put in a lot of effort to come up with an appropriate solution, including fully implementing and comparing 2 approaches.
Ultimately, we decided that introducing a new
type()
method onArgumentMatcher
is the best solution.As a result, it is now possible to update your custom matchers to implement varargs support, if you so desire.
Note that
ArgumentMatcher
is still a@FunctionalInterface
and can therefore still be written as a lambda.Massive thanks to community member @big-andy-coates who implemented this change.
What is the effect of this new method?
For varargs methods, there was previously a way to only match zero arguments, or two or more arguments, by using the exact number of matchers, i.e.
But following the pattern to match exactly one argument:
doesn't work, as
any
is "vararg aware", so Mockito matched theany
against each element of the varargs parameter, meaning it will match any number of arguments, i.e. the above would of matched all of these:With the new
type
method, it's now possible to differentiate matching calls with any exact number of arguments, or to match any number of arguments.