Skip to content

Naming a failure #526

@JakeWharton

Description

@JakeWharton

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions