Cannot mock wrapper types, String.class or Class.class #1734
Labels
Comments
|
This is working as intended. You can't mock strings. Use a real string instead. |
TimvdLippe
added a commit
that referenced
this issue
Nov 28, 2019
Mocking types that users not own [1] or are severely complicating test logic [2] leads to brittle or wrong tests. In particular, the StackOverflow answer is wrong, as the contract of java.util.Map is violated. When a new key is added to the Map, the stubbed return would be wrong. In Google we have used the DoNotMock annotation via ErrorProne [3] to annotate these types, as well as an internal list of types that can't be mocked (this includes several java.util types). We are using a custom Mockmaker to enforce this on run-time. Based on our successful experience with DoNotMock (we have seen a large reduction in bad/broken tests for types involved), we are proposing to open source this into Mockito itself. The DoNotMock annotation can be added to any type, e.g. classes and interfaces. If, in the type hierarchy of the class-to-be-mocked, there is a type that is annotated with DoNotMock, Mockito will throw a DoNotMockException. This would help preventing issues such as #1827 and #1734 which is in-line with the guidance on our wiki [1]. A follow-up change would allow us to define external types (like the java.util types) that can't be mocked. (We can't add the annotation to the types, as they live in the JDK instead.) [1]: https://github.com/mockito/mockito/wiki/How-to-write-good-tests#dont-mock-a-type-you-dont-own [2]: https://stackoverflow.com/a/15820143 [3]: https://errorprone.info/api/latest/com/google/errorprone/annotations/DoNotMock.html
TimvdLippe
added a commit
that referenced
this issue
Nov 19, 2021
Mocking types that users not own [1] or are severely complicating test logic [2] leads to brittle or wrong tests. In particular, the StackOverflow answer is wrong, as the contract of java.util.Map is violated. When a new key is added to the Map, the stubbed return would be wrong. In Google we have used the DoNotMock annotation via ErrorProne [3] to annotate these types, as well as an internal list of types that can't be mocked (this includes several java.util types). We are using a custom Mockmaker to enforce this on run-time. Based on our successful experience with DoNotMock (we have seen a large reduction in bad/broken tests for types involved), we are proposing to open source this into Mockito itself. The DoNotMock annotation can be added to any type, e.g. classes and interfaces. If, in the type hierarchy of the class-to-be-mocked, there is a type that is annotated with DoNotMock, Mockito will throw a DoNotMockException. This would help preventing issues such as #1827 and #1734 which is in-line with the guidance on our wiki [1]. A follow-up change would allow us to define external types (like the java.util types) that can't be mocked. (We can't add the annotation to the types, as they live in the JDK instead.) This PR also introduces the DoNotMockEnforcer interface which users can override to implement their special handling of types annotated with DoNotMock. [1]: https://github.com/mockito/mockito/wiki/How-to-write-good-tests#dont-mock-a-type-you-dont-own [2]: https://stackoverflow.com/a/15820143 [3]: https://errorprone.info/api/latest/com/google/errorprone/annotations/DoNotMock.html
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
Mockito can't not mock
String.classeven withorg.mockito:mockito-inline:2.28.2, but mocks custom final classes successfully.Version:
JUnit:
org.junit.jupiter:junit-jupiter:5.4.2Mockito-core:
org.mockito:mockito-core:2.28.2Mockito-inline:
org.mockito:mockito-inline:2.28.2Steps to reproduce:
Actual result:
Expected result: test with mock for
String.classis passed.The text was updated successfully, but these errors were encountered: