Open sageserpent-open opened 1 year ago
To provide some context, what I was trying to do was to use uTest's assertions from within a JUnit test - this is because I use a parameterised test framework that integrates nicely with JUnit, but prefer uTest's assertions for Scala:
In the meantime, I've discovered Expecty, which as a standalone assertion library suits my purposes better.
I imagine that the majority of users of uTest will be using the whole framework to structure their tests - so a test will be defined inline to get picked up by the test
macro rather than in a lambda, so this isn't likely to cause problems for them.
Feel free to close at will, but I'll leave this here just in case...
Using:
libraryDependencies += "com.lihaoyi" %% "utest" % "0.8.1" % Test
, running under IntelliJ.Code (Scala 3.3.0):
Hi, this is a minimisation of a problem I'm experiencing when using uTest with a parameterised test framework.
It actually runs either standalone or integrated under JUnit, so the original problem does not use the uTest
TestSuite
, just the uTest assertions - nevertheless I can reproduce it using the 'standard' approach.This test obviously fails, but the stack trace reported looks like this:
Note how the invocation of the lambda is correctly reported at line 13, as is the helper method on line 11, but the actual assertion location is approximated by line 16, rather than being precisely line 6.
This isn't a problem here as the example is simple, but for realistic tests it is inconvenient.
Changing the import to be
import utest.{TestSuite, Tests, test}
uses the standard assert inPredef
and fixes the stack trace:Oddly enough, if the helper
excised
is inlined into the lambda used to definedeferred
, then both approaches yield unsatisfactory stack traces, so I’m not completely sure how much of this is to do with uTest and how much is a quirk of the Scala implementation.