search

Adyen / adyen-react-native

Adyen React Native
https://docs.adyen.com/checkout
MIT License
42 stars 32 forks source link

fix(deps): update mockito monorepo to v5 (major) #475

Open renovate[bot] opened 2 weeks ago

renovate[bot] commented 2 weeks ago

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
org.mockito:mockito-inline 4.11.0 -> 5.2.0 age adoption passing confidence
org.mockito:mockito-junit-jupiter 4.11.0 -> 5.12.0 age adoption passing confidence

Release Notes

mockito/mockito (org.mockito:mockito-inline) ### [`v5.2.0`](https://togithub.com/mockito/mockito/releases/tag/v5.2.0) *Changelog generated by [Shipkit Changelog Gradle Plugin](https://togithub.com/shipkit/shipkit-changelog)* ##### 5.2.0 - 2023-03-09 - [25 commit(s)](https://togithub.com/mockito/mockito/compare/v5.1.1...v5.2.0) by Andriy Redko, Iulian Dragos, Roberto Trunfio, Róbert Papp, dependabot\[bot], jfrantzius, tobiasbaum - Fixes 2933: IOUtils does not depend on platform encoding any more [(#​2935)](https://togithub.com/mockito/mockito/pull/2935) - Execution with mockito-inline fails on platforms with EBCDIC as default encoding [(#​2933)](https://togithub.com/mockito/mockito/issues/2933) - Bump io.github.gradle-nexus:publish-plugin from 1.2.0 to 1.3.0 [(#​2932)](https://togithub.com/mockito/mockito/pull/2932) - Bump versions.bytebuddy from 1.14.0 to 1.14.1 [(#​2931)](https://togithub.com/mockito/mockito/pull/2931) - Bump com.diffplug.spotless from 6.15.0 to 6.16.0 [(#​2930)](https://togithub.com/mockito/mockito/pull/2930) - Bump com.google.googlejavaformat:google-java-format from 1.15.0 to 1.16.0 [(#​2928)](https://togithub.com/mockito/mockito/pull/2928) - Bump io.github.gradle-nexus:publish-plugin from 1.1.0 to 1.2.0 [(#​2924)](https://togithub.com/mockito/mockito/pull/2924) - Feature 2921 generic types [(#​2923)](https://togithub.com/mockito/mockito/pull/2923) - Bump com.github.ben-manes.versions from 0.45.0 to 0.46.0 [(#​2922)](https://togithub.com/mockito/mockito/pull/2922) - Use generic type information in TypeBasedCandidateFilter to circumvent type erasure [(#​2921)](https://togithub.com/mockito/mockito/issues/2921) - Make project relocatable by using relative paths in the OSGi test task [(#​2920)](https://togithub.com/mockito/mockito/pull/2920) - Cache misses due to OSGi tests referencing absolute paths [(#​2919)](https://togithub.com/mockito/mockito/issues/2919) - Bump versions.bytebuddy from 1.13.0 to 1.14.0 [(#​2918)](https://togithub.com/mockito/mockito/pull/2918) - Bump gradle/wrapper-validation-action from 1.0.5 to 1.0.6 [(#​2917)](https://togithub.com/mockito/mockito/pull/2917) - Bump com.diffplug.spotless from 6.14.1 to 6.15.0 [(#​2913)](https://togithub.com/mockito/mockito/pull/2913) - Bump versions.bytebuddy from 1.12.23 to 1.13.0 [(#​2912)](https://togithub.com/mockito/mockito/pull/2912) - Bump ru.vyarus.animalsniffer from 1.6.0 to 1.7.0 [(#​2911)](https://togithub.com/mockito/mockito/pull/2911) - Bump org.codehaus.groovy:groovy from 3.0.14 to 3.0.15 [(#​2910)](https://togithub.com/mockito/mockito/pull/2910) - Fixes [#​2905](https://togithub.com/mockito/mockito/issues/2905) : ThreadLocal classes can be mocked. [(#​2908)](https://togithub.com/mockito/mockito/pull/2908) - StackOverflow while mocking a ThreadLocal on Mockito 5.1.1 [(#​2905)](https://togithub.com/mockito/mockito/issues/2905) - Fix most Gradle warnings in build [(#​2904)](https://togithub.com/mockito/mockito/pull/2904) - Android CI improvements, improves [#​2892](https://togithub.com/mockito/mockito/issues/2892) [(#​2903)](https://togithub.com/mockito/mockito/pull/2903) - Bump com.diffplug.spotless from 6.14.0 to 6.14.1 [(#​2902)](https://togithub.com/mockito/mockito/pull/2902) - Bump versions.bytebuddy from 1.12.22 to 1.12.23 [(#​2901)](https://togithub.com/mockito/mockito/pull/2901) - CI on Android API level 33 for Java 11 compatibility testing [(#​2899)](https://togithub.com/mockito/mockito/pull/2899) - Bump kotlinVersion from 1.8.0 to 1.8.10 [(#​2897)](https://togithub.com/mockito/mockito/pull/2897) - Bump com.github.ben-manes.versions from 0.44.0 to 0.45.0 [(#​2895)](https://togithub.com/mockito/mockito/pull/2895) - Simplify and modernize Android Test module. [(#​2894)](https://togithub.com/mockito/mockito/pull/2894) - Set up Android Github Action pipeline. Fixes [#​2892](https://togithub.com/mockito/mockito/issues/2892) [(#​2893)](https://togithub.com/mockito/mockito/pull/2893) ### [`v5.1.1`](https://togithub.com/mockito/mockito/releases/tag/v5.1.1) *Changelog generated by [Shipkit Changelog Gradle Plugin](https://togithub.com/shipkit/shipkit-changelog)* ##### 5.1.1 - 2023-01-30 - [1 commit(s)](https://togithub.com/mockito/mockito/compare/v5.1.0...v5.1.1) by Andriy Redko - StackWalker.Option not found on Mockito 5.1.0 [(#​2891)](https://togithub.com/mockito/mockito/pull/2891) - StackWalker.Option not found on Mockito 5.1.0 [(#​2890)](https://togithub.com/mockito/mockito/issues/2890) ### [`v5.1.0`](https://togithub.com/mockito/mockito/releases/tag/v5.1.0) *Changelog generated by [Shipkit Changelog Gradle Plugin](https://togithub.com/shipkit/shipkit-changelog)* ##### 5.1.0 - 2023-01-29 - [12 commit(s)](https://togithub.com/mockito/mockito/compare/v5.0.0...v5.1.0) by Andriy Redko, Ashley, Róbert Papp, Stephan Schroevers, Tim te Beek, dependabot\[bot] - Fixes some mistakes and missing details in documentation [(#​2889)](https://togithub.com/mockito/mockito/pull/2889) - Bump com.diffplug.spotless from 6.13.0 to 6.14.0 [(#​2888)](https://togithub.com/mockito/mockito/pull/2888) - Clean up JDK-8 related code [(#​2883)](https://togithub.com/mockito/mockito/pull/2883) - Feat: reified mock overloads [(#​2882)](https://togithub.com/mockito/mockito/pull/2882) - Clean up JDK-8 related code [(#​2879)](https://togithub.com/mockito/mockito/issues/2879) - Bump assertj-core from 3.24.1 to 3.24.2 [(#​2875)](https://togithub.com/mockito/mockito/pull/2875) - Make sure the tests use mock maker with intended member accessor [(#​2872)](https://togithub.com/mockito/mockito/pull/2872) - Bump com.diffplug.spotless from 6.12.1 to 6.13.0 [(#​2871)](https://togithub.com/mockito/mockito/pull/2871) - Remove broken link from `CONTRIBUTING.md` [(#​2870)](https://togithub.com/mockito/mockito/pull/2870) - Update outdated badge 3.x to 5.x [(#​2869)](https://togithub.com/mockito/mockito/pull/2869) - Broken link in `CONTRIBUTING.md` [(#​2868)](https://togithub.com/mockito/mockito/issues/2868) - Set current version to 5.x in README and highlight changes [(#​2867)](https://togithub.com/mockito/mockito/pull/2867) - Annotate `Mockito#{mock,spy}(T... reified)` with `@SafeVarargs` [(#​2866)](https://togithub.com/mockito/mockito/pull/2866) - Make sure the tests use mock maker with intended member accessor [(#​2855)](https://togithub.com/mockito/mockito/issues/2855) - Improve examples for InOrder [(#​2843)](https://togithub.com/mockito/mockito/pull/2843) ### [`v5.0.0`](https://togithub.com/mockito/mockito/releases/tag/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](https://togithub.com/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](https://search.maven.org/artifact/org.mockito/mockito-subclass) 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`](https://togithub.com/mockito/mockito/issues/2798). 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](https://togithub.com/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 on `ArgumentMatcher` One of our most used public API's for customizing Mockito is the [`ArgumentMatcher` interface](https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/ArgumentMatcher.html). 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](https://togithub.com/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 on `ArgumentMatcher` 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](https://togithub.com/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. ```java long call(String... args); // Will match calls with exactly zero arguments: when(mock.call()).thenReturn(0L); // Will match calls with exactly two arguments: when(mock.call(any(), any())).thenReturn(0L); ``` But following the pattern to match exactly one argument: ```java when(mock.call(any())).thenReturn(0L); ``` doesn't work, as `any` is "vararg aware", so Mockito matched the `any` 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: ```java mock.call(); mock.call("a"); mock.call("a", "b"); ``` 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. ```java // Match any number of arguments: when(mock.call(any(String[].class))).thenReturn(1L); // Match invocations with no arguments: when(mock.call()).thenReturn(1L); // Match invocations with exactly one argument: when(mock.call(any())).thenReturn(1L); // Alternative to match invocations with exactly one argument: when(mock.call(any(String.class))).thenReturn(1L); // Match invocations with exactly two arguments: when(mock.call(any(), any())).thenReturn(1L); ``` Therefore, if you want to match 0 or more arguments, use `any(String[].class)`. If you want to match an exact number of arguments, use `any(String.class)` (and specify as many `any` matchers as arguments you want to match on). In a similar fashion, the behavior of `ArgumentCaptor.forClass` has changed as well. If you want to capture all arguments, use an `ArgumentCaptor` for `String[]`, otherwise `String`: ```java // Will capture 1 string @​Captor private ArgumentCaptor captor; // Will capture all strings @​Captor private ArgumentCaptor captor; ``` For more information, see the description and conversation in [pull request 2835](https://togithub.com/mockito/mockito/pull/2835) and [pull request 2807](https://togithub.com/mockito/mockito/pull/2807). At the same time, `ArgumentCaptor` is now fully type-aware. This allows for capturing specific subclasses on a generic method: ```java // Given: int simpleMethod(Collection arg); // When: mock.simpleMethod(Set.of()); mock.simpleMethod(List.of()); // Then: ArgumentCaptor> captor = ArgumentCaptor.forClass(List.class); verify(mock).simpleMethod(captor.capture()); assertThat(captor.getAllValues()).containsExactly(List.of()); ``` ##### Do I need to implement this new method? No, you don't need to. Mockito 5 declares a default implementation, returning `Void.type` as the type of an `ArgumentMatcher`. This essentially means that Mockito will not consider the type when handling varargs. However, if you do return a specific type, Mockito will consider this when matching arguments. As a result, this new method is not a source-breaking change, but is a bytecode-breaking change. All code working on Mockito 4 should work as-is when recompiled with Mockito 5.

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

This PR has been generated by Mend Renovate. View repository job log here.