On Thu, 29 Apr 2021 10:25:39 GMT, Pavel Rappo <pra...@openjdk.org> wrote:
>> On 28\/04\/2021 23\:51\, Pavel Rappo wrote\: >>> On Wed\, 28 Apr 2021 21\:22\:23 GMT\, Daniel Fuchs \<dfuchs at >>> openjdk\.org> wrote\: >>> >>>> It also avoids relying on an unspecified behavior of >>>> \`Assert\.assertEquals\`\. >>> >>> Which behavior is that\? If I recall correctly\, the test was written for >>> TestNG 6\.9\.5\, which provides a \[method to compare >>> collections\]\(https\:\/\/github\.com\/cbeust\/testng\/blob\/ef2d1199abff4e1b8fa4b1148c1314e776d7a044\/src\/main\/java\/org\/testng\/Assert\.java\#L508\-L517\)\. >> >> Exactly \- that API specification doesn\'t say whether elements >> that are arrays will be compared using shallow equals or deep >> equals\. >> >> The latest version of TestNG seems to have changed how elements >> in collections are compared\: >> https\:\/\/github\.com\/cbeust\/testng\/blob\/b60a1a13d274e5991f357d3ad1b41ce16c53de64\/core\/src\/main\/java\/org\/testng\/Assert\.java\#L143 >> >> \-\- daniel > >> Exactly - that API specification doesn't say whether elements >> that are arrays will be compared using shallow equals or deep >> equals. > > Fair enough. > > Since you are here, consider further improving diagnosability. The failed > comparison should provide more info. > Currently, assertEquals short-circuits by reporting only one property of the > lists that differs. If the lists are of different size, it's the size that is > reported. If the lists are of the same size, it's the leftmost non-equal > element that is reported, if any. In either case, there might be a lot of > info missing. Given that the comparables are relatively small, it makes sense > to print them out in full. @pavelrappo: done. ------------- PR: https://git.openjdk.java.net/jdk/pull/3776
