Mockito argThat does not work when used to match an iterator arg

Question

I am trying to verify a mocked service was called with an arguments in which the last is an iterator. This is the assertion in the test:

verify(myService).myMethod(
    ...,
    argThat(dataIterator -> iteratorEquals(dataIterator, dataToSave.iterator())));

and I have this TestHelper method:

public class TestHelpers {

    public static <T> boolean iteratorEquals(Iterator<T> x, Iterator<T> y) {
        while (x.hasNext() && y.hasNext()) {
            if (x.next() != y.next()) {
                return false;
            }
        }
        return x.hasNext() == y.hasNext();
    }
}

I was debugging the static method and it seems like the value returned from it is indeed true. Also, when debugging I can see the arguments passed to the service are as expected, but the assertion for some reason will fail in this case. When I am changing the assertion to this:

verify(myService).myMethod(
    ...,
    any());

the test will pass, meaning the problem is, indeed, with the iterator argument. This is the error I receive when the test fails:

myService.myMethod( ..., <custom argument matcher> ); Wanted 1 time: -> at ...(StorageClientTest.java:91) But was 0 times.

org.mockito.exceptions.verification.TooFewActualInvocations: myService.myMethod( ..., <custom argument matcher> ); Wanted 1 time: -> at ...(StorageClientTest.java:91) But was 0 times.

Am I doing something wrong here? why does the test fail?

Answer 1

The solution to this issue is to change the signature of the generic help method to return ArgumentMatcher and to move the lambda expression inside it:

public <T> ArgumentMatcher<Iterator<T>> equalsIterator(Iterator<T> compareTo) {
    return x -> {
        while (x.hasNext() && compareTo.hasNext()) {
            if (x.next() != compareTo.next()) {
                return false;
            }
        }
        return x.hasNext() == compareTo.hasNext();
    };
}

and I am calling it this way:

verify(myService).myMethod(
    ...,
    argThat(equalsIterator(dataToSave.iterator())));

Answer 2

I've never used Mockito.argThat, partially because I never had the need in defining custom argument matcher.

When I understand your use case correctly, then you want to test some class which used a stub of type MyService. And then you want to verify that the stub was called with an Iterable and that the elements in the Iterable have the same elements in the same order as another iterable.

In your case, I would use an ArgumentCaptor<> instead and then verify the captured argument against some expected values like that.

@ExtendWith(MockitoExtension.class)
class MyControllerTest {

    @Captor
    ArgumentCaptor<List<Data>> dataArgumentCaptor;

    @Test
    void save() {
        // Arrange
        final var service = mock(MyService.class);
        final var controller = new MyController(service);
        final var myExpectedData = List.of(new Data("Foo"), new Data("Bar"));
        
        // Act
        controller.save("Foo", "Bar");

        // Assert
        verify(service).save(dataArgumentCaptor.capture());
        assertThat(dataArgumentCaptor.getValue()).containsExactlyElementsOf(myExpectedData);
        // when you dont use assertj you could assert them also with plain junit like that:
        assertArrayEquals(dataToSave.toArray(), myExpectedData.toArray());
    }

    class MyService {
        public void save(List<Data> data) {
        }
    }

    record Data(String n) {
    }

    class MyController {
        private final MyService service;

        public MyController(MyService service) {
            this.service = service;
        }

        public void save(String... data) {
            final var list = Arrays.stream(data).map(Data::new).toList();
            service.save(list);
        }
    }
}

And for why your test passes, when you use any() instead, is that you only verify that your stub was called with something, but it is certainly not equal to what you expect.

And by using your TestHelpers method, which only returns true or false, you gain a better overview through assertj which elements you called it with and where it differs from the expected ones.