Skip to content
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

Fixes #583 fix bug when trying to capture null vararg #606

Closed
wants to merge 3 commits into from

Conversation

lukasz-szewc
Copy link
Contributor

Should fix just one issue - described in #583

@codecov-io
Copy link

codecov-io commented Aug 28, 2016

Current coverage is 88.24% (diff: 100%)

Merging #606 into master will increase coverage by <.01%

@@             master       #606   diff @@
==========================================
  Files           266        266          
  Lines          5161       5163     +2   
  Methods           0          0          
  Messages          0          0          
  Branches        847        848     +1   
==========================================
+ Hits           4554       4556     +2   
  Misses          429        429          
  Partials        178        178          

Sunburst

Powered by Codecov. Last update b669b4f...8a42098

@@ -141,13 +141,21 @@ private void captureVarargsPart(Invocation invocation) {
for (ArgumentMatcher m : uniqueMatcherSet(indexOfVararg)) {
if (m instanceof CapturesArguments) {
Object rawArgument = invocation.getRawArguments()[indexOfVararg];
for (int i = 0; i < Array.getLength(rawArgument); i++) {
((CapturesArguments) m).captureFrom(Array.get(rawArgument, i));
for (int i = 0; i < getLength(rawArgument); i++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of magically changing the length of the array, I would rather introduce an if-else around the for-loop, to make the intent clearer. With this implementation there is a hidden connection between getLength and getArgument

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true,
however code with if-else will be longer - but you know - there are no perfect solutions.

@TimvdLippe
Copy link
Contributor

Small implementation comment, other than that LGTM. Thanks for debugging and fixing this issue!

// then
verify(mock).varargs(argumentCaptor.capture());
Assertions.assertThat(argumentCaptor.getValue()).isNull();
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add another test with casting?

in the end we will have a test with mock.varargs((Type[]) null) and a test with mock.varargs((Type) null)

This allows thorough testing and documentation of each caseof.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Take a look at: should_capture_null_array_in_method_vararg. Is it sufficient ?

@@ -317,7 +317,7 @@ public void captures_correctly_when_captor_used_on_pure_vararg_method() throws E
}

@Test
public void should_capture_null_vararg() {
public void should_capture_null_single_argument_in_vararg_method() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is not explicit about casting.

Sorry I'm picky and on a mobile phone ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

take a look at second test method I have added : should_capture_null_array_in_method_vararg

@TimvdLippe
Copy link
Contributor

Regardless if we accept this PR or not, shall we postpone merging for 2.2 since we have a code freeze right now for the release candidate? I think our focus right now must be documentation to release ASAP.

@bric3 bric3 added this to the 2.1 milestone Aug 29, 2016
@bric3
Copy link
Contributor

bric3 commented Aug 29, 2016

I'm postponing this one with the rest of the Argument captor refactoring that will happen after mockito.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants