-
Notifications
You must be signed in to change notification settings - Fork 88
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
Naming a failure #526
Comments
Yeah I'd expect assertThat(runCatching { parse(version) }, name = version).isFailure() should work as a work-around? |
Ran into this myself and am working around it by adding this to my code:
|
Going to try to add name to assertFailure today |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Maybe I'm overlooking something, but I can't seem to name an
assertFailure
with any clarifying data.I have a test function calling a helper with a bunch of example failing cases. When one does not fail, I just get an "Expected failure but was success" with no real useful information. On the JVM the trace can help me, but this failure is JS-specific which means I get a near-useless trace.
Something like:
I have two proposals:
First, just let me name an
assertFailure
and put it in the message. Easy!Second, and a bit weirder, but what if there was an
Assert
-based failure-expecting version ofprop
/#521? If there was, I could doI haven't really thought through the implications of such a thing. And in general I'm not sure to what degree the outcome of #521 is solely for traversing "down" an instance vs. processing it with other types/functions.
Something to think about, though. Even if it's wrong for this specific situation (because proposal 1 seems obvious to do), maybe it's a thing that's still needed for actual instance-based property/function calls that we expect to throw?
The text was updated successfully, but these errors were encountered: