-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature async-describe -- Analysis of required design & usage changes #4641
Comments
@craigphicks thank you for this issue. There are already similar issues about this topic, see eg. #2116. I disagree with your analysis though. Mocha executes several runtime cycles, and the |
@juergba Thanks for your timely reply. I read your referenced post and the cycle doc, however I'm not sure what you disagree with - I can't see the conflict. (Obviously my suggestion is not the existing implementation but a modified version thereof.) I do understand the current implementation already use a tree, said tree implicitly defined by order the temporal order the nodes are read in. But it seems to me that the user-intended-order and that temporal-readin-order may diverge with async functions being passed to
is so that the user-intended-order can still be maintained. Do you think that is possible (in the general case) without passing a parent-node parameter? I appreciate your willingness to engage fully - but if you don't have the time I understand - feel free to not reply. |
Continuing with back compatibility, I think the cleanest approach would be conventional importing
and over ride the existing global |
Is your feature request related to a problem or a nice-to-have?? Please describe.
Async-describe seems to already be a requested feature (see Describe block with async function behaving weirdly #2975).
This post is a discussion of what interface changes would be needed and how usage would change.
Feature async-describe -- Analysis of required design & usage changes
It is understandable that async-describe doesn't currently work because there is no explicit reference to a parent
describe
object passed to anit
object being constructed. I assume theit
object constructor accesses a mocha global current-describe variable maintained only in the context of the main fiber (although I am not sure exactly how that is done).A design change to allow async-describe would require altering interfaces to explicitly pass the intended parent
describe
object, as well as a syncronization mechanism, e.g.,Notice the different spellings for
parentd
,parentdx
andparentdxx
to make clear here that they are not the same object. They needn't actually be different spellings because their scopes are different.The "optional"
await parentdx.sync()
should be judiciously placed by the user to prevent too many resources being allocated. It would also be convenient for eachdescribe
/it
to return a promise so thatcould be reduced to
Mocha doesn't know about resources, so only the user can decide that. Having more
describes
in play would allow moreit
s to be psuedo-concurrently running in the pipeline (taking advantage of IO waits, etc.), but eachdescribe
may require some resources which has a memory cost - some balance is required.However, even if
await parentd.sync()
orawait describe...
were never used,the mocha back end would still have a describe-tree with it-leaves that it could walk to get the proper reporting order even though the temporal order of starting each describe-node/it-leaf were not the proper reporting order.
The mocha back end would still have the independent ability (as I presume it does now) to limit/throttle the total number of
it
leaves executing concurrently in a (hidden to the user) mocha globalit
task pipelineBack compat
I think that by keying on the arguments passed to
describe
/it
that the async-describe feature could be back compatible with existing usage - same source, although using both async and non-async together might be tricky if it were actually desired (it is not expected to be desired).Perhaps new new function names, e.g.,
adescribe
andait
, could be used if they are going to return promises, but it is rather ugly.The text was updated successfully, but these errors were encountered: