You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Currently,
expect.same
andexpect.eql
require two things : acats.Eq
and 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
Comparison
abstraction, that should be roughly isomorphic towhere
None
would indicate equality/equivalence, whereasSome
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
andShow
as before, but using some better algorithm than what's currently available in weaver-test 0.8.x. Themyers 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.The text was updated successfully, but these errors were encountered: