<@U12AGS8JG> qq relaying a q from a colleague. do you have a suggestion on how can we register liste...

# kotest

[mitch]

@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

[sam]

Not sure I understand the ask. Do you have an example ?

[mitch]

we’ve been doing

test("something") {
    checkAll(
        defaultPropTestConfig().withListeners(beforeAfterListener),
        arbFoo,
        arbBar
    ) { foo, bar ->
       ...
    }
}

fun PropTestConfig.withListeners(vararg listeners: PropTestListener): PropTestConfig = ...

[mitch]

which works

[sam]

and you'd rather register the listener somewhere global than adding it to the prop test config ?

[mitch]

the ask was if it’s possible to do this (we use funspec)

context("foo") {
    beforeProperty {
       ...
    }
    
    test(...) { 
       etc...
    }
}

[sam]

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.

[sam]

checkAll is a suspend method so it has access to the coroutine context

[sam]

hmmm but it would need to completely surround the test

[sam]

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.

[sam]

https://github.com/kotest/kotest/issues/2161

[mitch]

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?

ContainerScope.checkAll(...)

[mitch]

oh wow thanks Sam!

[sam]

I like your syntax of the beforeProperty block

[sam]

but it needs to somehow register a lambda that's available to nested forAll / checkAlls

[mitch]

hmm yeah tricky

[sam]

it's straight forward to have the forAll / checkAlls look for a well known attribute in the coroutine context

[sam]

but contexts are immutable, so the registration part would need to add it and return a new context, like how withContext does

[sam]

If we allow scopes to register test case extensions, then those are capable of changing contexts

[sam]

anyway I'll have a play soon, this is a good idea

[mitch]

thanks!

[mitch]

@sam i think this is related https://github.com/kotest/kotest/issues/2171#issue-835864697