-
Notifications
You must be signed in to change notification settings - Fork 648
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
fix: Stacktrace is lost with one assertion in AssertSoftly, #4171 #4432
fix: Stacktrace is lost with one assertion in AssertSoftly, #4171 #4432
Conversation
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, a few minor suggestions
...s/kotest-assertions-core/src/jvmTest/kotlin/com/sksamuel/kotest/matchers/AssertSoftlyTest.kt
Outdated
Show resolved
Hide resolved
message.shouldContainInOrder( | ||
"The following assertion failed:", | ||
"1) Expecting actual not to be null", | ||
" at com.sksamuel.kotest.matchers.AssertSoftlyTest${'$'}1${'$'}1${'$'}9.invokeSuspend(AssertSoftlyTest.kt:162)" |
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.
Minor but blocking: let's remove line number 162 from expected string number 3, to make the test less fragile. Otherwise any refactoring/reformatting will break this test.
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.
That makes sense. However, this was one of the problems reported in the issue: an incorrect pointer in the stack trace. I'll move that test to a separate class to prevent it from affecting the other tests. What do you think?
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.
That makes sense. However, this was one of the problems reported in the issue: an incorrect pointer in the stack trace. I'll move that test to a separate class to prevent it from affecting the other tests. What do you think?
I concur - let's extract this test into its own file.
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.
Please take a look now, I changed the hardcoded line number to dynamically calculated variable.
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.
Please take a look now, I changed the hardcoded line number to dynamically calculated variable.
LGTM, started the build
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.
Please take a look now, I changed the hardcoded line number to dynamically calculated variable.
the following test is failing, and it might be related: "adds an Exception to an empty collection of assertion failures"
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.
Yes, I see that there is a test class marked to run on Linux only, which is why I didn't catch it failing in my local run.
I've already fixed it. The issue was that the expected exception class had changed, since any assertion failure in the assertSoftly
block should now be classified as a MultiAssertionError
, even if only one assertion fails.
it.message.shouldContainInOrder( | ||
"The following assertion failed:", | ||
"1) Expected map to match all assertions. Missing keys were=[], Mismatched values were=[(key, \"hi\" should have length 4, but instead was 2)], Unexpected keys were [].", | ||
" at com.sksamuel.kotest.matchers.maps.MapMatchersTestKt${'$'}matchMapTests${'$'}1${'$'}1${'$'}3.invokeSuspend(MapMatchersTest.kt:596)", |
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.
Same suggestion: can you remove 596
to make the test less fragile?
345b6c1
to
d943e3c
Compare
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.
nice!
It looks like
MultiAssertionError
factory method already handles properly following cases:size == 1 && subject != null
size == 1 && subject == null
So the easiest fix is to use
MultiAssertionError
even though there is just one assertion error - this way we don't loose the stacktrace. I provided appropriate test which covers the case presented in issue #4171