recursive comparison

[jlous]

Assertj's "usingRecursiveComparison" is incredibly useful.
I wish assertk could get something similar.

Granted, with kotlin's data classes I don't need it quite as often as with java, but sometimes that doesn't fit the design, sometimes the class isn't mine to change, and sometimes it's a java class

[evant]

Hm, would want to investigate more here. That method has a lot of features and I want to know how people are actually using it.

I'm actually concerned about the statement 'sometimes the class isn't mine to change'. It looks like by default usingRecursiveComparison compares by fields which seems like a bad idea to do for classes you don't own as it could easily break when it's implementation details are updated.

[jlous]

There are always ways to break things. But it is a fairly normal state of affairs that my code is required to produce or transform objects defined by a third party or in-house library that I have no timely control over. If they lack equals(), or have a broader concept of equality than my test needs, recursive comparison sure makes my life easier. So in those tests I switch to assertj in a heartbeat. That works fine fine, I just wish I could stick to the one library.

There is also the case where my production logic does not require any "equals", and adding it purely for test purposes could be considered pollution. I could write my own equality check in the test scope, but isn't eliminating that kind of boilerplate partly what assertion libraries are for?

[jlous]

But sure, if you use usingRecursiveComparison (or the deprecated isEqualToComparingFieldByFieldRecursively), then yes, you are explicitly requesting comparison on exposed fields. I respect if supporting that is not top priority, but I can't see why allowing me to do so would be a bad thing.

[evant]

but I can't see why allowing me to do so would be a bad thing.

But you can! This library was built to be extensible and if this works for your project then by all-means write an assertion to do a recursive field comparison.

The question is, is this generally useful to include in the library proper? That's where I'd want to gather some more information. It sounds like dealing with 3rd party code without equals implemented in the desired way is pretty common. I wonder if some kind of pluggable notion of equality would be useful.

Note: we do already have partial support for something like this with corresponds (allows you to pass your own equals method) and isEqualToWithGivenProperties (compares by the given properties, though it's not recursive), will think about how we can add to this cleanly.

[evant]

Also right now you have to chose between custom comparisons and the collection methods like containsExactly(), you can't really combine them, which maybe is something that can be improved.