Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revive "Strict Equality" for assertEquals() #521

Merged
merged 14 commits into from
Apr 16, 2022
Merged

Revive "Strict Equality" for assertEquals() #521

merged 14 commits into from
Apr 16, 2022

Conversation

valencik
Copy link
Collaborator

This PR is mostly a freshly rebased version of #225.

It is absolutely worth reviewing the discussion in the original PR. However, I've copy and pasted its description here:

Previously, MUnit had a subtyping constraint on assertEquals(a, b) so
that it would fail to compile if a was not a subtype of b. This was
a suboptimal solution because the compile error messages could become
cryptic in some cases. Additionally, this API didn't integrate with
other libaries like Cats that has its own cats.Eq[A,B] type-class.

Now, MUnit uses a new munit.Compare[A,B] type-class for comparing
values of different types. By default, MUnit provides a "universal"
instance that permits comparison between all types and uses the built-in
== method. Users can optionally enable "strict equality" by adding the
compiler option "-Xmacro-settings.munit.strictEquality" in Scala 2.
In Scala 3, we use the Eql[A, B] type-classes instead to determine
type equality (per http://dotty.epfl.ch/docs/reference/contextual/multiversal-equality.html)

Note: the first few commits are unrelated to this feature, I cleaned up
a few small quirks I noticed while working on this feature.

Fixes #189

Binary Incompatibility

This PR introduces a binary breaking changes to the following methods:

  • munit.Assertions.assertNotEquals
  • munit.Assertions.assertEquals
  • munit.FunSuite.assertNotEquals
  • munit.FunSuite.assertEquals

Rebasing notes:

The rebase got a little hairy. During it I ditched special casing for array comparisons, so 1503667 reintroduces it. Similarly, b28073f reintroduces the better string inequality error messages.

Olafur Pall Geirsson and others added 12 commits April 15, 2022 07:05
Previously, FailException had some custom nice-to-have features that
ComparisonFailException didn't have.
Previously, MUnit had a subtyping constraint on `assertEquals(a, b)` so
that it would fail to compile if `a` was not a subtype of `b`. This was
a suboptimal solution because the compile error messages could become
cryptic in some cases. Additionally, this API didn't integrate with
other libaries like Cats that has its own `cats.Eq[A,B]` type-class.

Now, MUnit uses a new `munit.Compare[A,B]` type-class for comparing
values of different types. By default, MUnit provides a "universal"
instance that permits comparison between all types and uses the built-in
`==` method. Users can optionally enable "strict equality" by adding the
compiler option `"-Xmacro-settings.munit.strictEquality"` in Scala 2.
In Scala 3, we use the `Eql[A, B]` type-classes instead to determine
type equality.
This is a fourth attempt at improving strict equality in MUnit
`assertEquals()` assertions.

* First attempt (current release version): require second argument to be
  a supertype of the first argument. This has the flaw that the compile
  error message is cryptic and that the ordering of the arguments affects
  compilation.
* Second attempt: use `Eql[A, B]` in Scala 3 and allow comparing any
  types in Scala 2. This has the flaw that it's a regression in some
  cases for Scala 2 users and that `Eql[A, B]` is not really usable
  in its current form, see related discussion
  https://contributors.scala-lang.org/t/should-multiversal-equality-provide-default-eql-instances/4574
* Third attempt: implement "strict equality" for Scala 2 with a macro
  and `Eql[T, T]` in Scala. This improves the situation for Scala 2,
  but would mean relying on a feature that we can't easily port to Scala 3.
* Fourth attempt (this commit): improve the first attempt (current
  release) by allowing `Compare[A, B]` as long
  as `A <:< B` OR `B <:< A`. This is possible thanks to an observation
  by Gabriele Petronella that it's possible to layer the implicits to
  avoid diverging implicit search.

The benefit of the fourth approach is that it works the same way for
Scala 3 and Scala 3. It's very nice that we can avoid macros as well.
The Scala 3 (dotty) tests now use compareSubtypeWithSupertype instead
of compareSupertypeWithSubtype. Additionally, the "unrelated" test was
not seeing the context code above and so I've moved all the code into
compileErrors.
@valencik valencik self-assigned this Apr 15, 2022
@valencik valencik added this to the MUnit v1.0 milestone Apr 15, 2022
@valencik valencik requested review from gabro and olafurpg April 15, 2022 17:30
Copy link
Member

@olafurpg olafurpg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was a lot of work! Thank you so much for reviving this PR ❤️ LGTM.

Only a few minor suggestions, feel free to ignore them

munit/shared/src/main/scala/munit/Clue.scala Outdated Show resolved Hide resolved
@@ -28,9 +28,6 @@ object FullStackTraceFrameworkSuite
extends BaseStackTraceFrameworkSuite(
Array("-F"),
"""|at munit.Assertions:failComparison
| at munit.Assertions:failComparison$
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice 👍

|
|The following import might make progress towards fixing the problem:
|
| import munit.CustomCompare.fromCustomEquality
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a shame these suggestions have false positives like this 🙈

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmmm, yeah this is a bummer.
I think it's related to scala/scala3#9685

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice find! I left a comment in that issue about the fact that we can reproduce without inline scala/scala3#9685 (comment)

tests/shared/src/test/scala/munit/AssertionsSuite.scala Outdated Show resolved Hide resolved
valencik and others added 2 commits April 16, 2022 07:43
Co-authored-by: Ólafur Páll Geirsson <olafurpg@gmail.com>
Co-authored-by: Ólafur Páll Geirsson <olafurpg@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrong order of arguments for assertEquals
2 participants