Thanks for reporting this @Soamid

This one is tricky, as you pointed out the cause is how we deal with visited nodes, we compare them without evaluating the field location to be able to track potential cycles. Take for example a Person class with a neighbor field, it results in a cycle when comparing them: John has Tim as neighbor, Tim has John, but when looking at Tim.neighbor we fall back to John, if we evaluate it we cycle back falling in an infinite recursion.

To detect visited nodes, we compare them by reference, if we check the node location your test succeeds but the cycle detection does not work anymore, the Person example Tim.neighbor refers to John but the location is different from the John root object (location is neighbor)

Your test actually succeeds if we build the datastores object with new instances of data1, data2 and data3 because the visited nodes detection will find the references are different, try this with:

  private static DataStore createDataStore(boolean reverse) {
    DataStore dataStore = new DataStore();
    dataStore.store1.addAll(reverse ? list(new Data("987"), new Data("456"), new Data("123"))
        : list(new Data("123"), new Data("456"), new Data("987")));
    dataStore.store2.addAll(reverse ? list(new Data("987"), new Data("456")) : list(new Data("456"), new Data("987")));
    return dataStore;
  }

Having said that, it would be great to support both your use case and the cycle detection but I'm not sure if this is possible, I need to do think about it more. Comparing unordered collection increases the likeliness of the issue as it requires comparing all elements to all expected elements (cross product) leading to duplicate dual values when both collections share the same elements.

@Soamid I have found a way to address this issue, basically by caching the diff computed per node so that when the same node is visited again, it returns the diff (this addresses also the potential cycles)
Thanks for the detailed report that was really helpful.

Oh, that's great. :) Thank you for the investigation! It will be really helpful in my case because I have no control if the objects are copied or only referenced in two places (they are populated by DB framework and I use AssertJ in integration tests to write more complex assertions). Having one object in two collections usually is not a good model design, but that's another story and I have to live with it. :D

@Soamid It would be great if you could check on your side that this was fixed properly, building assert is fairly straightforward (mvn install should do), then you can use the built snapshot version locally to run the unit tests. If you don't have time and can't it's okay.

The recursive comparison unit tests are a challenge because there is so much to cover, we test individual features on small tests but we can't cover all the possible combination, this is why tests from real projects are super valuable.

I've checked it today and everything works now, not only on this small example but also in my main project (which is quite complex and I use this assertion in multiple scenarios). I've simply uncommented the assertion and all turned green. Thank you once again and looking forward to the release. :)

Awesome, appreciate you took the time to test.