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
Fix/bug 1551 cce on smart not null answers #1576
Fix/bug 1551 cce on smart not null answers #1576
Conversation
Codecov Report
@@ Coverage Diff @@
## release/2.x #1576 +/- ##
=================================================
+ Coverage 88.49% 88.57% +0.07%
- Complexity 2408 2425 +17
=================================================
Files 299 299
Lines 6059 6099 +40
Branches 739 752 +13
=================================================
+ Hits 5362 5402 +40
+ Misses 515 514 -1
- Partials 182 183 +1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, good work! Awesome to see extensive test coverage as well. Thank you very much for your contribution 😄
for (int i = 0; i < parameterTypes.length; i++) { | ||
Type argType = parameterTypes[i]; | ||
if (returnType.equals(argType)) { | ||
return invocation.getArgument(i).getClass(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Patouche This will throw a NPE if the argument value is null
! Can you write a test?
if (argType instanceof GenericArrayType) { | ||
argType = ((GenericArrayType) argType).getGenericComponentType(); | ||
if (returnType.equals(argType)) { | ||
return invocation.getArgument(i).getClass(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Patouche This will throw a NPE if the argument value is null
! Can you write a test?
This solves a large number of edge-cases where `null` will actually remove the runtime ClassCastException. This essentially negates the whole MockitoCast ErrorProne check. We can still not support every use case, but causing a NPE instead of a CCE does not seem to make this worse. I am still running internal tests within Google to see if there are any regressions, but I already saw that some of the test failures we had with ByteBuddy were resolved with this particular patch. Note that this now fully closes #357. A previous PR resolved the same issue with ReturnsSmartNulls: #1576. Fixes #357
This solves a large number of edge-cases where `null` will actually remove the runtime ClassCastException. This essentially negates the whole MockitoCast ErrorProne check. We can still not support every use case, but causing a NPE instead of a CCE does not seem to make this worse. I am still running internal tests within Google to see if there are any regressions, but I already saw that some of the test failures we had with ByteBuddy were resolved with this particular patch. Note that this now fully closes #357. A previous PR resolved the same issue with ReturnsSmartNulls: #1576. Fixes #357
* Fix mockito#1551 : Add support for Generic in ReturnsSmartNulls * Fix mockito#1551 : Integrate support for generic using varargs * mockito#1551 : Fix typo and some missing documentation
This solves a large number of edge-cases where `null` will actually remove the runtime ClassCastException. This essentially negates the whole MockitoCast ErrorProne check. We can still not support every use case, but causing a NPE instead of a CCE does not seem to make this worse. I am still running internal tests within Google to see if there are any regressions, but I already saw that some of the test failures we had with ByteBuddy were resolved with this particular patch. Note that this now fully closes mockito#357. A previous PR resolved the same issue with ReturnsSmartNulls: mockito#1576. Fixes mockito#357
This PR intends to fix #1551. For fix it, the
ReturnsSmartNulls
answer use now some reflection to find the correct return type instead of thejava.util.Object
.When the return type can be found, it will start to retrieve empty values using the answer
ReturnsMoreEmptyValues
&ReturnsEmptyValues
before creating a new mock instance.As you may notice in tests, there is still one case where the return type cannot be found. In this case, the
Answer
will return anull
instead ofObject
mock.I think, it may be possible to improve this code. Any suggestion will be welcome !