Make tests for everything not in the promises/a+ test suite about native-promise-only

[getify]

Another test to make sure is included: https://gist.github.com/domenic/43d3228e141ea225ea6e

+@domenic

[getify]

This just bit me that I don't have these ES6 API surface tests, which led to a regression bug #11 in Promise.all(..) and Promise.race(..). :(

[stefanpenner]

@getify have these tests been pulled out yet?

[getify]

@stefanpenner i believe @smikes is still working on that.

[smikes]

Yes, these exist -- at least partial coverage -- as a separate npm module promises-es6-tests

[getify]

https://www.npmjs.org/package/promises-es6-tests

[getify]

I'm not clear on how this project native-promise-only can adhere to the structure of that test suite yet, given this assertion:

When a polyfill or other Javascript implementation of Promises is being tested, these functions should modify the passed-in globalScope object, not the global object.

That sorta violates the spirit of how polyfills work. They intentionally test the real global, by name, and aren't usually set up to accept another "global" to test against.

I suppose the best an adapter for this lib could do is the very hacky:

1. Test if there is already a global.Promise object. If so, save a ref to it, but then delete it.
2. Load NPO
3. Pull the NPO provided version of global.Promise off the global so that the global is clean again.
4. Restore the saved ref, if any, from (1) of the original Promise back to global.
5. Add the NPO provided Promise to this fake global in the adapter.

That's a pretty awkward integration path, but I don't see any other way at the moment.

[smikes]

That's exactly what the adapter does. It's kludgy but the goal was to make poly fills, shims, and native implementations testable in browser or console scopes, for example if there is already a native Promise implementation on global.Promise. 

Note that the existence of global.Promise is not a problem ; it's just ignored by the test suite.

On Thu, Aug 14, 2014 at 11:57 AM, Kyle Simpson [email protected]
wrote:

I'm not clear on how this project native-promise-only can adhere to the structure of that test suite yet, given this assertion:

When a polyfill or other Javascript implementation of Promises is being tested, these functions should modify the passed-in globalScope object, not the global object.
That sorta violates the spirit of how polyfills work. They intentionally test the real global, by name, and aren't usually set up to accept another "global" to test against.
I suppose the best an adapter for this lib could do is the very hacky:

1. Test if there is already a global.Promise object. If so, save a ref to it, but then delete it.
2. Load NPO
3. Pull the NPO provided version of global.Promise off the global so that the global is clean again.
4. Restore the saved ref from (1) if any.
5. Add the NPO provided Promise to this fake global in the adapter.

That's a pretty awkward integration path, but I don't see any other way at the moment.

Reply to this email directly or view it on GitHub:
#6 (comment)

[getify]

Note that the existence of global.Promise is not a problem ; it's just ignored by the test suite.

It's not a problem for the test suite. But it's a problem for the polyfill, which ignores doing its job if the global.Promise is there. So that's what I meant about the awkwardness of creating forced tests around something whose design goal is to be ignorable in newer environments. IOW, it's unfortunate to have to force a newer environment to pretend Promise isn't there just so the polyfill will even load itself.

In fact, I think it actually is an interesting philosophical question... should a polyfill be tested in a newer environment that has the thing and doesn't need the polyfill? One on hand, I'd say enthusiastically YES!!!, but OTOH I'd say, reluctantly, "perhaps not?" I don't have a good conclusion yet.

[smikes]

Personally I'd most prefer a poly fill that 

1. Tests for correct functionality and replaces global. Promise if not correct 
2. Always returns its own implementation, for testing and in order to try parallel implementations. 

Since both node 0.11 and chrome ship the version of v8 with incorrect promises, what the polyfill does in that context is an open question.

[edited to correct email formatting, fix typo, and remove quoted text]

[smikes]

Though that might not fit some people's definition of a "polyfill" vs a "shim" vs whatever. I am not really clear on the terminology there.

BTW when I said "what the polyfill does is an open question" I mean what it should do is an open question. What it actually does is well-defined. It leaves the buggy implementation of promises in place, by design.

[getify]

+1