Currently, expect.same and expect.eql require two things : a cats.Eq and a cats.Show, which implies that the user has no power whatsoever over the rendering that happen when the comparison is negative.
These methods should be amended to take a sort of Comparison abstraction, that should be roughly isomorphic to
trait Comparison[A] {
def diff(received: A, expected: A) : Option[String]
}
where None would indicate equality/equivalence, whereas Some would imply differences, and would contain a textual representation of the differences. This approach would offer a greater flexibility for users to inject different rendering logic based on the data types being compared. For instance, JSON Merge patch could be a suitable way to render of diff JSON values.
A default implicit instance of the comparison could be provided, relying on Eq and Show as before, but using some better algorithm than what's currently available in weaver-test 0.8.x. The myers diff algorithm, currently used by munit, seems to be an interesting contender.
From my shared experience with @keynmol having to rely on a third party like expecty for this kind of thing, I think it'd be preferable to roll our own implementation, in particular if it's reasonably approachable.
Baccata
commented
5 months ago
Currently,
expect.sameandexpect.eqlrequire two things : acats.Eqand acats.Show, which implies that the user has no power whatsoever over the rendering that happen when the comparison is negative.These methods should be amended to take a sort of
Comparisonabstraction, that should be roughly isomorphic towhere
Nonewould indicate equality/equivalence, whereasSomewould imply differences, and would contain a textual representation of the differences. This approach would offer a greater flexibility for users to inject different rendering logic based on the data types being compared. For instance, JSON Merge patch could be a suitable way to render of diff JSON values.A default implicit instance of the comparison could be provided, relying on
EqandShowas before, but using some better algorithm than what's currently available in weaver-test 0.8.x. Themyers diffalgorithm, currently used by munit, seems to be an interesting contender.From my shared experience with @keynmol having to rely on a third party like
expectyfor this kind of thing, I think it'd be preferable to roll our own implementation, in particular if it's reasonably approachable.