-
Notifications
You must be signed in to change notification settings - Fork 1.4k
zio-test: Remove the "... + x more" feedback from zio-test outputs
#9900
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
Conversation
485e014 to
e3430f6
Compare
6768862 to
85be7d7
Compare
| s"""$name($spacer$indentedBody$spacer)""" | ||
|
|
||
| case string: String => | ||
| val surround = if (string.split("\n").length > 1) "\"\"\"" else "\"" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
string.split("\n").length > 1 not a great way to check if a String contains a Character 😕
53bb9df to
8daf5f9
Compare
| val body = labels0 | ||
| .zip(product.productIterator) | ||
| .map { case (key, value) => | ||
| s"${(key + " =").faint} ${PrettyPrint(value)}" | ||
| } | ||
| .toList | ||
| .mkString(",\n") | ||
| val isMultiline = body.split("\n").length > 1 | ||
| val indentedBody = indent(body, if (isMultiline) 2 else 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This wasn't great. We were building a String with \n as separator to then split it twice on this same character. I implemented an optimised version of this algorithm
be23ade to
58b60ad
Compare
262c98d to
fd887c8
Compare
test/shared/src/main/scala-2.13/zio/test/PrettyPrintVersionSpecific.scala
Outdated
Show resolved
Hide resolved
| Iterator.continually("") | ||
| } | ||
|
|
||
| def prettyPrintProduct(product: Product): String = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
previous, non-optimized, compatible with Scala 2.12, version of the algorithm
27cd172 to
4f5ade0
Compare
|
@kyri-petrou @hearnadam I took all your comments into account |
hearnadam
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM aside from the test changes.
|
|
||
| case set: Set[_] => | ||
| prettyPrintIterator(set.iterator, set.size, className(set)) | ||
| // For why `Nil.type` is used. See https://github.com/zio/zio/pull/9900#discussion_r2121380398 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of a comment, can you add a test for Vector.empty? (or any other non-List empty Seq)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
Interestingly, the previous code was printing Nil for Vector.empty while now it correctly prints Vector() 🙂
I keep the comment as using _: Nil.type is not usual code
| } | ||
|
|
||
| for { | ||
| _ <- ZIO.unit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you avoid the ZIO/for completely?
val x =
val y = ...
assertTrue(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
f773da7 to
f0a851f
Compare
It's extremely frustrating to have a test framework which doesn't show/report the data when there's a diff between the result of the test execution and the expected result
I always have to add some debug
printlnand relaunch my tests, to be able to see this diff.IMO, that shouldn't be the case.
zio-test should show me the result data and the expected data in its output so I can fix my test
Effectively reverting #8692
I tried to optmise a bit the code so that performances aren't impacted too much by this change.
I tested the perfs with this test (coming from the initally reported issue #8644):
With the code optimisations, the test indeed takes a bit longer to execute, but only around ~550-600ms, which isn't "forever" in my opinion (the author of the original ticket was reporting, I quote, "The exists assertions take forever")
I have a similar computer to the reporter of the issue: Macbook Pro M3 36Gb of RAM.