https://kotlinlang.org logo
#kotest
Title
# kotest
m

mitch

03/09/2021, 1:22 PM
@sam qq relaying a q from a colleague. do you have a suggestion on how can we register listeners to say checkAll per scope e.g. nested in a context? Right now we've been using explicit function calls / passing various explicit proptestconfig that carries a listener with it. Curious if you have a better idea around that
s

sam

03/09/2021, 1:22 PM
Not sure I understand the ask. Do you have an example ?
m

mitch

03/09/2021, 1:27 PM
we’ve been doing
Copy code
test("something") {
    checkAll(
        defaultPropTestConfig().withListeners(beforeAfterListener),
        arbFoo,
        arbBar
    ) { foo, bar ->
       ...
    }
}

fun PropTestConfig.withListeners(vararg listeners: PropTestListener): PropTestConfig = ...
which works
s

sam

03/09/2021, 1:28 PM
and you'd rather register the listener somewhere global than adding it to the prop test config ?
m

mitch

03/09/2021, 1:29 PM
the ask was if it’s possible to do this (we use funspec)
Copy code
context("foo") {
    beforeProperty {
       ...
    }
    
    test(...) { 
       etc...
    }
}
s

sam

03/09/2021, 1:32 PM
the property test library can't rely on special things in the framework, or it would only be usable from kotest ....but I think we could possibly make this work.
checkAll is a suspend method so it has access to the coroutine context
hmmm but it would need to completely surround the test
I think with some trickery we could make lifecycle methods on property testing work from the DSL of kotest. I need to think about it a little more.
m

mitch

03/09/2021, 1:38 PM
yeah, i was looking around the codebase, lifting checkAll above the test or somehow implicitly injecting a container scope to checkAll but might be quite a massive change.. something like this?
Copy code
ContainerScope.checkAll(...)
oh wow thanks Sam!
s

sam

03/09/2021, 1:38 PM
I like your syntax of the beforeProperty block
but it needs to somehow register a lambda that's available to nested forAll / checkAlls
m

mitch

03/09/2021, 1:39 PM
hmm yeah tricky
s

sam

03/09/2021, 1:39 PM
it's straight forward to have the forAll / checkAlls look for a well known attribute in the coroutine context
but contexts are immutable, so the registration part would need to add it and return a new context, like how withContext does
If we allow scopes to register test case extensions, then those are capable of changing contexts
anyway I'll have a play soon, this is a good idea
m

mitch

03/09/2021, 1:41 PM
thanks!
5 Views