Summary
We saw this when updating from AssertJ 3.19.0 to 3.20.0. It appears that AbstractMapAssert#containsOnlyKeys is mutating the map that we're asserting on, which leads to test failures in our case. This is happening on an instance of org.springframework.util.MultiValueMapAdapter
Example
var underlyingMap = new HashMap<String, List<String>>();
underlyingMap.put("Hello", List.of("World"));
var multiValueMap = CollectionUtils.toMultiValueMap(underlyingMap);
// This assertion passes
assertThat(multiValueMap).containsOnlyKeys("Hello");
// This assertion fails, as `multiValueMap` and `underlyingMap` are now empty
assertThat(multiValueMap).containsOnlyKeys("Hello");
The issue seems to have been introduced in #2167, and is caused by this use of Map#remove on a "clone" of the Map being asserted on. In our case that Map is a Spring MultiValueMapAdapter, which delegates operations to the underlying Map that it was constructed from. The remove call on the clone delegates to multiValueMap#remove which in turn delegates to underlyingMap#remove.
Summary
We saw this when updating from AssertJ 3.19.0 to 3.20.0. It appears that
AbstractMapAssert#containsOnlyKeysis mutating the map that we're asserting on, which leads to test failures in our case. This is happening on an instance oforg.springframework.util.MultiValueMapAdapterExample
The issue seems to have been introduced in #2167, and is caused by this use of
Map#removeon a "clone" of theMapbeing asserted on. In our case thatMapis a SpringMultiValueMapAdapter, which delegates operations to the underlyingMapthat it was constructed from. Theremovecall on the clone delegates tomultiValueMap#removewhich in turn delegates tounderlyingMap#remove.