search

tc39 / test262

Official ECMAScript Conformance Test Suite
Other
2.36k stars 461 forks source link

Explicit asynchronous resolution functions #848

Open jugglinmike opened 7 years ago

jugglinmike commented 7 years ago

Currently, asynchronous functions signal their completion through the invocation of a globally-defined function named $DONE. This function is used both in passing and failure cases: "completed" tests are interpreted as "passing" or "failing" based on the truthiness of the first parameter.

This behavior enables a pattern that has become common across the tests for Promises: the function may be specified to both arguments of Promise.prototype.then, e.g.

Promise.resolve().then($DONE, $DONE);

In order to account for the expected case, tests have been authored such that promises are resolved with a falsey value. The "implicit failure" mechanism will be triggered if the promises are rejected with some truthy value.

However, if the promises are rejected with a falsey value, these tests will spuriously pass.

To avoid this, I'd like to simplify the implementation of $DONE to only signal a passing test and introduce a new function to signal failure unconditionally. The name $ASYNCERROR would complement the existing $ERROR function, but I'm open to suggestion on that. Such a helper function would also be useful in asserting that "fulfillment" paths are not taken (which was an issue in gh-846, currently under review).

The above example would then look like:

Promise.resolve().then($DONE, $ASYNCERROR);

What do folks here think?

caitp commented 7 years ago

I don't have a problem with the idea, but I don't think this proposal should be a blocker for my async tests in the pipeline.

I don't expect implementations tested against test262 will be having problems with accidentally rejecting falsy values in tests that all reject with truthy values during the time between #846 landing, and a fix for #848 landing

jugglinmike commented 7 years ago

I agree completely. My silence on gh-846 has been due to personal time constraints, not any perceived dependency on the issue described here. Sorry for the confusion!