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.

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

Merged
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@ import io.kotest.matchers.should
import io.kotest.matchers.shouldBe
import io.kotest.matchers.shouldNot
import io.kotest.matchers.shouldNotBe
import io.kotest.matchers.string.beEmpty
import io.kotest.matchers.string.contain
import io.kotest.matchers.string.endWith
import io.kotest.matchers.string.shouldContain
Expand Down Expand Up @@ -154,6 +155,21 @@ class AssertSoftlyTest : FreeSpec({
}
}


"Should not loose stacktrace with only one assertion" {
pientaa marked this conversation as resolved.
Show resolved Hide resolved
shouldThrow<AssertionError> {
assertSoftly {
null should beEmpty()
}
}.run {
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)"
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Member

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"

Copy link
Contributor Author

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.

)
}
}

"Receiver version" - {
"works on a receiver object" {
shouldThrow<AssertionError> {
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -596,7 +596,11 @@ private fun matchMapTests(contextName: String) = wordSpec {
mapOf("key" to "hi") should matcher("key" to { it shouldHaveLength 4 })
}
}.also {
it.message shouldBe """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 []."""
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)",
Copy link
Member

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?

)
}
}

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -176,8 +176,6 @@ inline fun <reified T> ErrorCollector.runWithMode(mode: ErrorCollectionMode, blo
internal fun List<Throwable>.toAssertionError(depth: Int, subject: Printed?): AssertionError? {
return when {
isEmpty() -> null
size == 1 && subject != null -> AssertionError("The following assertion for ${subject.value} failed:\n" + this[0].message)
size == 1 && subject == null -> AssertionError(this[0].message)
else -> MultiAssertionError(this, depth, subject)
}?.let {
stacktraces.cleanStackTrace(it)
Expand Down