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.

Sign up for GitHub

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

Jump to bottom

Wrong line numbers using assertEquals when helper method declared in seperate file #855

Open
AugustNagro opened this issue Nov 26, 2024 · 4 comments
Open

Wrong line numbers using assertEquals when helper method declared in seperate file #855

AugustNagro opened this issue Nov 26, 2024 · 4 comments

Comments

@AugustNagro
Copy link

AugustNagro commented Nov 26, 2024 •
edited
Loading

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

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.
@AugustNagro 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
@tgodzik
Copy link
Contributor

tgodzik commented 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.

@AugustNagro
Copy link
Author

Yeah I also understand that I'm trying to do something against the grain here. If it were configurable at least that would be great.

@tgodzik
Copy link
Contributor

tgodzik commented Nov 28, 2024

Ok, it looks like it would never print the stack trace and that was on purpose, fixing it in #856

Should help with your case too or at least shed more light on it

AugustNagro added a commit to AugustNagro/magnum that referenced this issue Nov 29, 2024
@AugustNagro
Spec Refactor:
3116df6 
* Spec.build method is removed. Specs are now fully declarative and the DbType is responsible for implementation.
* Tests are improved and now shared between database specs insteads of duplicated. The increased coverage exposed some tangential issues which are also resolved in this MR (see below). Note: switched from munit assertEquals -> assert until fix for scalameta/munit#855 (comment) is released.

Additional changes:

* No longer need to handle null when using DbCodec.biMap, or implementing DbCodec.readSingle
* When implementing DbCodec, new method readSingleOption must be defined
* Support optional products in outer-join queries (see test OptionalProductTests)
AugustNagro added a commit to AugustNagro/magnum that referenced this issue Nov 29, 2024
@AugustNagro
Spec Refactor:
f608001 
* Spec.build method is removed. Specs are now fully declarative and the DbType is responsible for implementation.
* Tests are improved and now shared between database specs insteads of duplicated. The increased coverage exposed some tangential issues which are also resolved in this MR (see below). Note: switched from munit assertEquals -> assert until fix for scalameta/munit#855 (comment) is released.

Additional changes:

* No longer need to handle null when using DbCodec.biMap, or implementing DbCodec.readSingle
* When implementing DbCodec, new method readSingleOption must be defined
* Support optional products in outer-join queries (see test OptionalProductTests)
AugustNagro added a commit to AugustNagro/magnum that referenced this issue Nov 29, 2024
@AugustNagro
Spec Refactor:
5362214 
* Spec.build method is removed. Specs are now fully declarative and the DbType is responsible for implementation.
* Tests are improved and now shared between database specs insteads of duplicated. The increased coverage exposed some tangential issues which are also resolved in this MR (see below). Note: switched from munit assertEquals -> assert until fix for scalameta/munit#855 (comment) is released.

Additional changes:

* No longer need to handle null when using DbCodec.biMap, or implementing DbCodec.readSingle
* When implementing DbCodec, new method readSingleOption must be defined
* Support optional products in outer-join queries (see test OptionalProductTests)
* Switched to latest scalafmt version to prevent OOM in OracleTests
AugustNagro added a commit to AugustNagro/magnum that referenced this issue Nov 29, 2024
@AugustNagro
Spec Refactor:
77b0121 
* Spec.build method is removed. Specs are now fully declarative and the DbType is responsible for implementation.
* Add Spec.prefix method
* Change Spec.seek nullOrder, Spec.orderBy direction and nullOrder to be database Default
* Tests are improved and now shared between database specs insteads of duplicated. The increased coverage exposed some tangential issues which are also resolved in this MR (see below). Note: switched from munit assertEquals -> assert until fix for scalameta/munit#855 (comment) is released.

Additional changes:

* No longer need to handle null when using DbCodec.biMap, or implementing DbCodec.readSingle
* When implementing DbCodec, new method readSingleOption must be defined
* Support optional products in outer-join queries (see test OptionalProductTests)
* Switched to latest scalafmt version to prevent OOM in OracleTests
* Make Frag, Query, Update, Returning into regular classes
* Frag.returningKeys method which uses ResultSet.getGeneratedKeys
* Make MySq insertReturning throw, since we shouldn't define 2-query repository methods.
@AugustNagro AugustNagro mentioned this issue Nov 29, 2024
Merged
AugustNagro added a commit to AugustNagro/magnum that referenced this issue Dec 1, 2024
@AugustNagro
Spec Refactor (#73)
a2334fd 
* Spec Refactor:

* Spec.build method is removed. Specs are now fully declarative and the DbType is responsible for implementation.
* Add Spec.prefix method
* Change Spec.seek nullOrder, Spec.orderBy direction and nullOrder to be database Default
* Tests are improved and now shared between database specs insteads of duplicated. The increased coverage exposed some tangential issues which are also resolved in this MR (see below). Note: switched from munit assertEquals -> assert until fix for scalameta/munit#855 (comment) is released.

Additional changes:

* No longer need to handle null when using DbCodec.biMap, or implementing DbCodec.readSingle
* When implementing DbCodec, new method readSingleOption must be defined
* Support optional products in outer-join queries (see test OptionalProductTests)
* Switched to latest scalafmt version to prevent OOM in OracleTests
* Make Frag, Query, Update, Returning into regular classes
* Frag.returningKeys method which uses ResultSet.getGeneratedKeys
* Make MySq insertReturning throw, since we shouldn't define 2-query repository methods.

* reduce duplication with shared DbCodec.readSingleOpt impl

* remove unused def in MySqlDbType

* fix SqlLogger error formatting

* use keyColumsArr in Returning

* make sure no expr duplication in sql macro

* add test to ensure that embedded frag param exprs are evaluated only once
@tgodzik
Copy link
Contributor

tgodzik commented Dec 2, 2024

The release is running, let me know if that helps https://github.com/scalameta/munit/actions/runs/12119500567

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tgodzik @AugustNagro