Highlight the munitExecutionContext parasitic peculiarity in docs

[danicheg]

It turns out, the default munitExecutionContext is parasitic, so that could lead to deadlocks in some cases. Using that EC as default might be reasonable. But from my way of thinking, most users could expect it uses the default Scala's EC (which is FJ-pool). It'd be good if docs mention this behavior. What do you think?

[armanbilge]

I think the default of a parasitic EC should possibly be reconsidered for munit 1.0.

[armanbilge]

In #134 (comment) @olafurpg says

Is it OK/expected that munitExecutionContext is parasitic by default? Users can always override it if they want something else. I felt that a parasitic EC was the best default to 1) have deterministic test behaviors and 2) keep stack traces clean.

The problem is that a parasitic EC can deadlock, which creates problems when testing async code.

However, I agree with the goal to achieve deterministic test behaviors. In fact, it is possible to achieve this without using a parasitic EC and thus without deadlocks. For example, Cats Effect introduced such a test runtime in typelevel/cats-effect#2276 and I'd be happy to help port something similar here.

Clean stack traces is a trickier one, but this is more a problem with async computation in general (and IMHO is out-of-scope for munit to solve).

[olafurpg]

MUnit was primarily designed with non-async code in mind, where the parasitic execution context is not a problem. As long as stack traces remain clean for sync tests then I’m open for ideas how to avoid deadlocks in async tests.

[armanbilge]

Thanks, that's helpful feedback.

@valencik and I discussed this a bit, and probably not worth blocking 1.0 over this one. I think this can still be fixed in a minor release, so long as it is not a regression for sync tests (which is a requirement anyway), since for async tests it is arguably a bug fix.