LeoColman

    LeoColman

    3 years ago
    But I'm not sure if it's possible
    dave08

    dave08

    3 years ago
    @LeoColman What problem are you currently having with it?
    LeoColman

    LeoColman

    3 years ago
    I'm not very used to coroutines yet, and I don't really know how they work
    I'm afraid to put everything in a
    runBlocking
    block and it bugs someone's code
    For instance giving every Spec and TestContext a CouroutineScope
    dave08

    dave08

    3 years ago
    The advantage of coIt is that it gives the user the choice to use coroutines support, too much magic sometimes leads to hard-to-reason-about testing... Mockk.io does it like that, and Spek doesn't even want to introduce support, so I ended up making my own functions. The coroutine scope is usually at the base of the whole hierarchy, it is responsible for canclelling all the child jobs and cleaning up.
    LeoColman

    LeoColman

    3 years ago
    Do you think it would be better to add a
    co { XX }
    block instead of giving Coroutines to everybody?
    I personally find adding
    coIt
    and similar useless, as the user can add
    runBlocking
    inside the code, and the extra line of code would be the very same
    dave08

    dave08

    3 years ago
    Also extra nesting...
    LeoColman

    LeoColman

    3 years ago
    One extra nesting, you're right
    The problem with
    coIt
    , as you mentioned in the GH Issue is that it wouldn't apply for everything, such as FreeSpec
    dave08

    dave08

    3 years ago
    Right... that's where I got stuck.
    But an infix co could fix that
    It just needs to be applied to the test itself, not the groupings...
    LeoColman

    LeoColman

    3 years ago
    This is what I've been trying so fare
    I'm thinking that having all the scopes as suspended might be a good idea, but I'm not sure how to validate that.
    I'm fixing the scenarios that SKSamuel setup, but I'm not sure if that's enough
    That branch is kind of confusing, I'm doing some refactorings in the SpecRunner to allow for that suspended context
    dave08

    dave08

    3 years ago
    Ktor also runs completely on coroutines, and all the routes have scopes. You need to make sure that a launch or async that fails in one test or test class doesn't cancel all the others... isActive can be called in a suspend function to see if its still active and launch has a job you can test.
    This seems to be their "root" https://github.com/ktorio/ktor/blob/master/ktor-server/ktor-server-core/jvm/src/io/ktor/application/Application.kt . Notice the SupervisorJob to avoid one failing request to cancel the others...
    And it gets disposed by cancelling only the root scope, which in turn cancels all the children..
    LeoColman

    LeoColman

    3 years ago
    Could you help me elaborate a test case that exercises that? I can't think of code that tests that
    dave08

    dave08

    3 years ago
    I just had a VERY funny bug (maybe with my
    coIt
    ...?) that when I added a test function, junit runs the old ones, and doesn't find the new one... tried clearing/invalidating IDE and gradle caches, to no avail...
    For an example, I'm not too sure what you need... I'm not too familiar with junitPlatform. I think that using the same SupervisorJob at the root, and launch a coroutine for each parallel test (with a new thread.asDispatcher()) and then surrounding each test in a
    coroutineScope { }
    builder might do the trick (to ensure all the cancellation is handled properly), the thing is that I don't know where the tests are actually executed (in TestEngine?), there you might need a single runBlocking to wait for everything to complete (it might be the one to use the SupervisorJob...).