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

Naming a failure #526

Open
JakeWharton opened this issue Apr 2, 2024 · 3 comments
Open

Naming a failure #526

JakeWharton opened this issue Apr 2, 2024 · 3 comments

Comments

@JakeWharton
Copy link
Contributor

JakeWharton commented Apr 2, 2024

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:

@Test fun parses() {
  assertParseFailure("1")
  assertParseFailure("1.2")
  assertParseFailure("1.2.a")
  assertParseFailure("1.2.3.4")
  assertParseFailure("1.2.3-beta")
}
private fun assertParseFailure(version: String) {
  assertFailure { parse(version) }
    .isIntanceOf<ISE>()
    ...
}

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 of prop/#521? If there was, I could do

assertThat(version)
  .havingFailure("parses", ::parse)
  .isInstanceOf<ISE>()
  ...

I 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?

@evant
Copy link
Collaborator

evant commented Apr 2, 2024

Yeah I'd expect assertFailure to have the same additional arguments as assertThat. Also, we still have the result assertions so

assertThat(runCatching { parse(version) }, name = version).isFailure()

should work as a work-around?

@dalewking
Copy link

Ran into this myself and am working around it by adding this to my code:

inline fun assertFailure(description: String? = "lambda", f: () -> Unit): Assert<Throwable> {
    @Suppress("TooGenericExceptionCaught") // Intentionally capturing all exceptions.
    try {
        f()
    } catch (t: Throwable) {
        return assertThat(t, "exception thrown from $description")
    }
    fail("expected failure but $description completed successfully")
}

@JakeWharton
Copy link
Contributor Author

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants