anyList() causes a type mismatch when stubbing or verifying a method that expects List<List<String>>, and anyListOf() doesn’t work for nested lists. What’s the proper way to match a nested list parameter in Mockito?
Having worked with Mockito for quite a few years, I’ve hit this exact issue when dealing with nested generics. The easiest and most reliable fix is to use any() and cast it to the expected type. Mockito doesn’t really understand nested generics well, so a cast keeps things clean:
import static org.mockito.ArgumentMatchers.any;
when(mock.name(anyInt(), (List<List<String>>) any())).thenReturn(someValue);
any() matches everything, and the cast convinces the compiler that we’re dealing with List<List<String>>. Simple and works every time.
Yeah, @ian-partridge’s approach is solid. I’ve run into the same thing while working on older Java 7 projects, and sometimes teams prefer sticking to anyList() out of habit. In that case, you can still make it work with a small tweak just suppress the generics warnings:
@SuppressWarnings("unchecked")
List<List<String>> nestedList = anyList();
when(mock.name(anyInt(), nestedList)).thenReturn(someValue);
Since anyList() returns a raw List, the warning suppression lets you pass it as List<List<String>> without complaints. Not as clean as Ian’s method, but totally fine for legacy codebases.
You both covered the type-matching side really well. I’ll add something I’ve learned the hard way sometimes you don’t just want any list, you want to validate that the nested structure is actually meaningful. In that case, argThat gives you way more control:
import static org.mockito.ArgumentMatchers.argThat;
when(mock.name(
anyInt(),
argThat(l -> l != null && !l.isEmpty())
)).thenReturn(someValue);
On Java 7 you’d use an anonymous class instead of a lambda, but the idea is the same. This approach helps when you want correctness as well as flexibility useful when the list contents influence logic.