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
MySuite:
+ this works 0.005s
==> X MySuite.this fails 0.021s munit.ComparisonFailException: /home/augustnagro/prog/test-projects/munit-helper-bad-trace/src/test/scala/MySuite.scala:4
3:class MySuite extends munit.FunSuite {
4: mySharedTest(this, "Postgres")
5:}
values are not the same
=> Obtained
abc
=> Diff (- obtained, + expected)
-abc
+abd
at munit.Assertions.failComparison(Assertions.scala:278)
[error] Failed: Total 2, Failed 1, Errors 0, Passed 1
[error] Failed tests:
[error] MySuite
[error] (Test / test) sbt.TestsFailedException: Tests unsuccessful
[error] Total time: 1 s, completed Nov 26, 2024, 12:09:19 AM
If assertEquals printed the stacktrace (like assert() and as suggested in #782 ), that would make things much better.
The text was updated successfully, but these errors were encountered:
AugustNagro
changed the title
Wrong line numbers using assertEquals in helper method declared in seperate file
Wrong line numbers using assertEquals when helper method declared in seperate file
Nov 26, 2024
I've been wondering whether hiding the stack trace is that useful. I think it was done to avoid having traces from munit, but this behaviour is flaky as seen here.
When using a MUnit test inside a helper function that lives in a different file than the FunSuite subtype, the error output is very unhelpful.
I've made a minimal reproducer here: https://github.com/AugustNagro/munit-helper-bad-trace
If assertEquals printed the stacktrace (like assert() and as suggested in #782 ), that would make things much better.
The text was updated successfully, but these errors were encountered: