Ok so it s optional for generated tests it might be nice to

Question

Ok so it s optional for generated tests it might be nice to clear that up in the docs slightly smiling face Also does minutest support running `suspend` functions I find tests with `runBlocking` all over the place can be hard to read

dmcg · Answer

Good point on willRun

dmcg · Answer

I ve avoided thinking about suspend because every block would need a runBlocking version

dmcg · Answer

It s on my list but I m not a asynchronous coroutines user so hard

dmcg · Answer

If you can provide some use cases I m up for the challenge

dave08 · Answer

Really only the root block that s being run needs runBlocking and all the blocks under it can inherit it s coroutineContext Also it would be nice to provide the CoroutineScope to those contexts to allow users to `launch` from that scope

dave08 · Answer

But then I don t know the inners of Minutest enough

dave08 · Answer

Also `inline fun`s don t need to suspend as long as they re running under the runBlocking

dmcg · Answer

When you say root block I guess you mean the rootContext It takes a builder block which may or may not be inline I can t remember offhand

dmcg · Answer

There is a TestDescriptor passed into every block you just don t have to acknowledge its existence It currently provides access to the name of the test but we could smuggle a coroutine context through it too

dave08 · Answer

If the root block runs before all contexts in every test and then the context and then the test then the root block needs the runBlocking and the context and test need to inherit its CoroutineScope

dave08 · Answer

You mean that you already have `it` used by the `TestDescriptor` and `this` used by the fixture Yeah it s a nice solution to provide a `scope` property anyways the scope is only used for `launch`ing or `async` calls most of the time I call `suspend` functions that don t require one

robfletcher · Answer

I don t think you d need coroutine aware versions of the DSL methods If the DSL methods accepted `suspend` functions it wouldn t matter if the actual tests involved coroutines or not I mean theoretically there s a small performance penalty but we re talking about unit tests here it s not going to be noticeable

dmcg · Answer

I m running to catch up with this discussion I ve not internalised any coroutine lore

dmcg · Answer

Am I right in thinking that if I make the DSL function types `suspend` all the way through then at some point I will be responsible for providing the coroutine context the problem being that there are potentially different contexts that could be used

dmcg · Answer

I ve committed this with < dave08> s help as a starting point

dave08 · Answer

The context can always be changed with `withContext` and the likes so the starting point is probably `runBlocking` The solution I suggested is more of a hack I had used with Spek that made things livable I agree with < robfletcher> that having everything `suspend` would be a better solution if possible

dmcg · Answer

I ve taken a look at that approach but ATM it s blocked pun not intended on a class `Test` that implements `TestLet` that is a typealias for the thing that is actually run and would need to be `suspend` But `Suspend function type is not allowed as supertypes`

dmcg · Answer

I can probably rejig things not to have the problem but I m going to need to understand the ramifications

dave08 · Answer

Where did you put `suspend` AFAIK it should be in the typealias itself where did you get the error

dmcg · Answer

It was in the TestLet typealias but that is implemented by Test which is not allowed

dave08 · Answer

Why `by f` Maybe just implement the delgation yourself just one invoke function no Or you really need the inheritance

dmcg · Answer

Implementing the delegation doesn t help the problem is that you can t implement a suspend function type

dmcg · Answer

I probably don t need the inheritance it simplified things

dmcg · Answer

but I could just fetch the property everywhere

dave08 · Answer

I meant without the inheritance from the lambda

dave08 · Answer

An operator invoke might delegate to the lambda

dave08 · Answer

Then you don t need to fetch the property you could maybe have an interface for that

dmcg · Answer

I think that would loose the suspend ness that I have to chase through the code unless that delegation was the point where I runBlocking

dmcg · Answer

in which case I have to work out how to supply the a provided CoroutineContext I think

dmcg · Answer

As I say working on gut feel not experience here

dave08 · Answer

The scope can be gotten by surrouding any suspend fun with `coroutineContext ` once you have a base scope like runBlocking its running under Like I said the scope is only needed for using coroutine builders for concurency like launch or async but to run regular suspend functions you wouldn t need a scope

dave08 · Answer

At the same time coroutineScope allows cancelling on it without cancelling the main scope if the main scope has a SupervisorJob

dmcg · Answer

OK over my head now

dmcg · Answer

< dave08> what s the minimum coroutine support necessary to get you to stay at our little party

dave08 · Answer

Sounds daunting in the beginning but the docs are pretty clear on structured concurrency which is what you might need to understand so that the tests don t get stuck or all cancel etc The minimum is a runBlocking around each test and passing its scope to the test a bit unefficient but that could avoid the other problems

dave08 · Answer

Thanks for all your efforts wink