I have a function under test that takes an `Iterab...

# strikt

[rocketraman]

I have a function under test that takes an Iterable<T> and returns a subset of that given a single element T. For example, assume my function has signature fun <T> Iterable<T>.priorAdjacent(elem: T): List<T>.

Currently use the pattern: expectThat(elems) { get { priorAdjacent(elems[3]) } isEqualTo elems.slice(1..2) } which reads nicely and produces understandable failure messages. That being said, is that the best approach?

[robfletcher]

Yes, basically. You could always define an extension function if it’s something you use repeatedly

fun <T> Assertion.Builder<Iterable<T>>.priorAdjacent(elem: T): Assertion.Builder<List<T>> =
  get { priorAdjacent(elem) }

[robfletcher]

then you could write the assertion as

expectThat(elems)
  .priorAdjacent(elems[3])
  .isEqualTo(elems.slice(1..2))

[christophsturm]

interesting, I always try to have everything that can possibly fail in the expectThat(…) part, and use get() only to navigate the result

[christophsturm]

never thought of expectThat(subject).get{ testedMethod}

[robfletcher]

Yeah, I was assuming in this case that wasn’t really the point of the test, but maybe I misunderstood

[rocketraman]

The priorAdjacent is the function under test yes. So this isn't idiomatic then?

[rocketraman]

I thought expectThat(subject) was the expected way to use Strikt. No pun intended 🙂

[christophsturm]

the typical way is to do call the method under test before and use strikt for the asserting, but maybe thats not the only good way to use it…

[rocketraman]

Yeah, what's nice about this style is that the failure message is "complete" -- it shows the input, the functions performed on it, the actual and expected output.

[rocketraman]

Examples:

▼ Expect that [Elem(idx=0), Elem(idx=1), Elem(idx=2)]:
  ▼ priorAdjacent(elems[1], ::isAdjacent):
    ✗ is equal to []
            found [Elem(idx=0)]

vs

▼ Expect that [Elem(idx=0)]:
  ✗ is equal to []
          found [Elem(idx=0)]

The only way to make sense of the latter message is via its context in the test code.

[robfletcher]

Another way would be

expectCatching {
  elems.priorAdjacent(elems[3])
}
  .isSuccess()
  .isEqualTo(elems.slice(1..2))

[rocketraman]

I suppose the advantage of that is that it handles exceptions with a nicer test failure, but it still relies on context to know which element is actually failing:

▼ Expect that Success([Elem(idx=0), Elem(idx=1), Elem(idx=2)]):
  ✓ is success
  ▼ value:
    ✗ is equal to [Elem(idx=1), Elem(idx=2)]
            found [Elem(idx=0), Elem(idx=1), Elem(idx=2)]

[christophsturm]

maybe there could be an alias to get thats nicer suited for this use case. maybe call?