Thread
#strikt
    sloydev

    sloydev

    1 year ago
    Hello! I was looking for a way to "group" multiple assertions with a descriptive message, but I did't find an easy (and non-verbose) way to do this in the docs or exploring the API. I implemented something custom, but I wonder if there is a better "native" way. Does anybody know a way to do something like this with the Strikt API?
    expectThat(output) {
      should("Replace anonymous id") {
        get { anonymousId() }.isEqualTo("anonymous_user")
        get { context().traits().anonymousId() }.isEqualTo("anonymous_user")
      }
      should("Remove advertisingId and deviceId") {
        get { advertisingId() }.isNull()
        get { deviceId() }.isNull()
      }
    }
    So I get error messages like these:
    ✗ Replace anonymous id
        ▼ "5c6b6c02-4dd2d":
          ✗ is equal to "anonymous_user"
                  found "5c6b6c02-4dd2d"
        ▼ "5c6b6c02-4dd2d":
          ✗ is equal to "anonymous_user"
                  found "5c6b6c02-4dd2d"
      ✗ Remove advertisingId and deviceId
        ▼ "32c85c4d-c39b897c":
          ✗ is null
        ▼ "c55911907ad":
          ✗ is null
    For reference, the custom function
    should
    looks like this:
    private fun <T> Assertion.Builder<T>.should(
      description: String,
      assertions: Assertion.Builder<T>.() -> Unit
    ) {
      compose(description) {
        assertions()
      } then {
        if (allPassed) pass() else fail()
      }
    }
    robfletcher

    robfletcher

    1 year ago
    That’s a nice idea
    It’s the
    and
    function but with a description
    I like it
    sloydev

    sloydev

    1 year ago
    Thanks! 🙂 From your reaction I get that there is no current alternative for this 😛
    If you think it's useful I wouldn't mind contributing it, but I get a bit lost in the internal design of the library. I suppose there's a better approach than my quick hack
    robfletcher

    robfletcher

    1 year ago
    I think the implementation is correct, it could just be a member function on
    Assertion.Builder
    rather than being an extension.
    sloydev

    sloydev

    1 year ago
    And what do you think of the naming? I used
    should
    because it's the first thing that came to mind and fitted our test case, but super subjective. Is it ok? Or can you think of a more strikt-ish name? An existing name like
    and
    or
    describedAs
    ? A new name like
    should
    or
    group
    or something else?
    robfletcher

    robfletcher

    1 year ago
    Yeah, I need to give that some thought