Emil Kantis
06/09/2021, 8:04 PMx should...
and look for a good assertion that does what I want it to, perhaps throwing in some word that fits. Would it make sense to just bake inspectors into the regular set of collector matchers and deprecate collection matchers which take a predicate in favour of ones that use matcher-blocks?sam
06/09/2021, 8:07 PMEmil Kantis
06/09/2021, 8:07 PMforAll
-> shouldAll
which asserts every element passes the assertions
forNone
-> shouldContainNone
which asserts no element passes
forOne
-> shouldContainSingle
which asserts only a single element passed
forAtMostOne
-> shouldContainAtMostOne
which asserts that either 0 or 1 elements pass
forAtLeastOne
-> shouldContainAtLeastOne
which asserts that 1 or more elements passed
forAtLeast(k)
-> shouldContainAtLeast(k)
which is a generalization that k or more elements passed
forAtMost(k)
-> shouldContainAtMost(k)
which is a generalization that k or fewer elements passed
forAny
which is an alias for forAtLeastOne -> shouldContainAtLeastOne
forSome
-> shouldContainSome
which asserts that between 1 and n-1 elements passed. Ie, if NONE pass or ALL pass then we consider that a failure.
forExactly(k)
-> shouldContain(k)
which is a generalization that exactly k elements passed. This is the basis for the implementation of the other methodssam
06/09/2021, 8:13 PMEmil Kantis
06/09/2021, 8:18 PMsubject.should {
it.name shouldBe "karl"
it.age shouldBeGreaterThan 25
}
In this case we enable
val subjects = listOf(...)
subjects.shouldAll {
it.age shouldBeInRange 18..65
it.name shouldBeIn listOf("hans", "greta")
}
It feels like a natural analogue between single <-> collection assertions to me at least 🙂sam
06/09/2021, 8:19 PMsubjects.shouldMatchAtMost(k) { }
subjects.forAtMost(k) { }
Emil Kantis
06/09/2021, 8:21 PMsam
06/09/2021, 8:22 PMEmil Kantis
06/09/2021, 8:37 PMsam
06/09/2021, 8:37 PMEmil Kantis
06/09/2021, 8:48 PMsam
06/09/2021, 8:49 PMwasyl
06/09/2021, 8:59 PMsomeList shouldHaveSingleElement { it.label == "expected" }
, that is piggyback on the existing collection matchers, but pass another matcher as the expectationsam
06/09/2021, 9:00 PMsomeList.shouldHaveSingleElement(::matcher) ?
wasyl
06/09/2021, 9:01 PMsam
06/09/2021, 9:02 PMsomeList.forOne { a shouldDoSomething b }
wasyl
06/09/2021, 9:03 PMCollection<T>.shouldHaveSingleElement(p: (T) -> Boolean)
already. What I miss most often is a way to compare two lists with custom comparatorsam
06/09/2021, 9:04 PMwasyl
06/09/2021, 9:06 PMdata class Foo(val str: String, val callback: () -> Unit)
callback is usually different so I want to compare by str
only. Right now we have
fun List<Foo>.toSnapshot() = "$str"
fooList.toSnapshot() shouldBe expectedFooList.toSnapshot()
I don’t know what I’d like, but something like
fooList.something(expectedList) { actual, expected -> actual.str == expected.str }
but I’m pretty tired and I don’t know if it makes sense anymore, the snapshot actually looks better now. So, disregard I suppose 😛(T) -> Boolean
selector variant, like fun <T, C : Collection<T>> C.shouldContain(t: T)
doesn’t have a shouldContain { it % 2 == 0 }
variant like shouldHaveSingleElement
doessam
06/09/2021, 9:08 PMEmil Kantis
06/09/2021, 9:09 PMsam
06/09/2021, 9:10 PMwasyl
06/09/2021, 9:10 PM(T) -> Boolean
too, since it’ll be more flexible. In fact, only a matcher would be required, and the basic X shouldBe y
could be x shouldBe eq(y)
, and the usual comparison would be just a handy helperEmil Kantis
06/09/2021, 11:54 PMrunTests
and implement the matcher contract like this?
way too late here now, but I'll setup a draft PR tomorrow to facilitate discussionjohisa
06/10/2021, 8:19 AMshould...
convention I believe