Replace specs2 with munit #4216
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
iRevive
force-pushed
the
topic/munit-kernel-laws
branch
from
e671306 to
d2b73e9
Compare
iRevive
commented
Dec 27, 2024
| // we try iterating a few times to get canceled in the middle | ||
| if (i > Bound) { | ||
| IO.pure(skipped(s"attempted $i times and could not reproduce scenario")) | ||
| IO.println(s"attempted $i times and could not reproduce scenario") |
There was a problem hiding this comment.
So, it's not a direct equivalent. But I cannot think of anything better.
iRevive
force-pushed
the
topic/munit-kernel-laws
branch
2 times, most recently
from
4c319c2 to
7bc5906
Compare
|
…holy crap |
|
General 20k LOC changeset. Nothing to worry about 😅 |
|
Specs2 model feels more strict. With munit the following code compiles and the test is green, but it's never being executed: test("leaky io") {
IO(sys.error("boom"))
}The compiler doesn't throw any warning, either. I hope I didn't miss such cases. |
djspiewak
requested changes
Dec 27, 2024
This one is concerning, to be sure. We've historically had a bunch of problems with this, and we do have a ton of tests which throw exceptions in various cases. We should explore our own variant of |
iRevive
commented
Dec 30, 2024
iRevive
commented
Dec 30, 2024
iRevive
force-pushed
the
topic/munit-kernel-laws
branch
from
3d60f3f to
9f68a30
Compare
|
I think the next step on this is probably to go through and surgically break some subtle things one at a time and make sure the test suite still catches it. |
iRevive
commented
Jan 2, 2025
iRevive
commented
Jan 2, 2025
|
Sorry, I snuck a new test in here. |
iRevive
commented
Jan 3, 2025
Comment on lines
52
to
58
| new ValueTransform( | ||
| "Other", | ||
| { | ||
| case r if !r.isInstanceOf[Unit] && !r.isInstanceOf[Prop] => | ||
| sys.error(s"Unexpected value of type ${r.getClass.getName}: $r") | ||
| } | ||
| ) |
There was a problem hiding this comment.
This transformer ensures the result type is Unit or Prop.
From the munit perspective, that's a valid test:
test("some test") {
1 == 2
}However, it should use assert:
test("some test") {
assert(1 == 2)
}Here are all the fixed tests that were exposed by this transformer: 9186d4b
iRevive
commented
Jan 3, 2025
No worries. I've backported the test. |
|
So for some reason, |
|
My best guess is that If you didn't clean the project, it may use the old cached native artifacts. |
|
For some reason, munit seems a lot more prone to hanging tests without timeouts in some failure cases. For example, if you remove the |
|
I did some flipping tests before, and they were timing out correctly. However, CPU usage skyrocketed to 1300%, and the fans went crazy. Today I decided to use nix env, and the result was different: Hangs forever. CPU usage is normal, though. |
|
Interesting. I'm on Java 23 and for me it was a forever hang with normal CPU. |
|
Do you use Temurin by any chance?
I'm testing on Darwin Aarch64. |
Fascinating! And somewhat terrifying. I wonder why there's such a significant difference between the distributions? |
|
Seems to be related: scalameta/munit#730. override def munitExecutionContext: ExecutionContext = ExecutionContext.global |
|
I did some extra testing on the Azul JVM. After several reruns of the 65dc9ad - this change fixes hanging behavior on all JVMs. |
|
This change still seems to hang forever for me: diff --git a/core/shared/src/main/scala/cats/effect/IOFiber.scala b/core/shared/src/main/scala/cats/effect/IOFiber.scala
index 9e0357b734..39c44fd37e 100644
--- a/core/shared/src/main/scala/cats/effect/IOFiber.scala
+++ b/core/shared/src/main/scala/cats/effect/IOFiber.scala
@@ -697,7 +697,7 @@ private final class IOFiber[A](
*/
suspend()
}
- } else if (finalizing == state.wasFinalizing && !shouldFinalize() && outcome == null) {
+ } else if (finalizing == state.wasFinalizing && outcome == null) {
/*
* If we aren't canceled or completed, and we're
* still in the same finalization state, loop onMaybe that's a unique one. I'm trying out a few more which hung previously. |
Roughly 1 in 10 runs hangs, no matter what JVM you use. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow up to #3787.
The whole PR is purely focused on the migration. There are options to build more usable test abstractions and utilities, but I don't want to do it without proper thinking.