domenic/promise-tests

DEPRECATED: use https://github.com/promises-aplus/promises-tests instead!

promise-tests's Issues

Race conditions

Due to the fact that it is preferred to have callbacks called asynchronously, there is a delay between when a promise is resolved/rejected and when the callbacks are called. If during that delay .then is called, depending on the implementation, the newly added callbacks could very well be called twice: once by the delayed handler and once by the code that, in .then(), detects that the promise is already done.

A test to check against that would basically use .then(), .resolve() and .then() again, making sure that two callbacks are called only, in the proper order.

This is slightly pedandic, but I ran into that bug when implementing promises in my multitasker and other may have the same issue with this corner case. See https://github.com/JeanHuguesRobert/l8

Faster timeouts

When debugging an implementation it's a pain to have to wait for 2 second time-outs. Given that any half decent implementation will complete each test in just a few milliseconds, how about we set time-outs to 500ms by default, with some option to extend them?

Controversies (Deferred implementation case)

@domenic such tool is great idea, but code used for tests is at some points controversial. I think it's good to discuss it further.

Deferred implementation obeys all the concepts that are tested, but when setup, it fails mosts of the tests. Reasons for that are:

Deferred doesn't create extra promise when it doesn't make sense to create one (performance reasons). Following:

promise.then()

Will just return input promise, and tests of this project assume that it should return newly created promise. I don't agree that it's necessary. As you mentioned in your document then is a mechanism for applying a transformation to a promise. If there's not transformation provided I think it's very ok to return same promise.

In Deferred promise can be rejected only with an error object. It goes also other way, promise cannot be fulfilled with an error object. In result all tests that try to reject promise with some regular value, fail.

In my point of view, rejection should be only about errors, this the reason why it's solved that way in Deferred.

However the way I've solved it, I'm not 100% on now. Thing is in JavaScript we can throw also other objects and I believe it should be matched. So with 0.7 I plan to change behavior so it adheres with throw, if value can be thrown, we should be able to use it for rejection.

Still I'm wondering: When you work in real world applications, do you reject promises with not error objects? If so what's the case? and if you do, do you also sometimes throw not error objects in synchronous functions (this should go in pair in my opinion)?

In my fork I've updated the tests, so they don't test empty then calls and do all rejects with errors, then Deferred passes 100%:

Test script never exits on old versions of Node

On old versions of node (0.6 and 0.7) this script never terminates.

I'm running the command

$ promise-tests all adapter.js

and it gets as far as

✔ 40 tests complete (189 ms)

but then it never completes, you can see an example build running on travis-ci which will get killed by travis once 30 mins have expired. The exact same library on 0.8 works fine.

devDependencies should be dependencies.

Is hurting tildeio/rsvp.js#2

Doesn't ever try test with `null`

You never try fulfilling a promise with null as the value. Since getting the 'What counts as a promise and what counts as a value' part of promises/A and promises/A+ correct is one of the trickier things to do, I think it would be useful to have a test case that tries resolving with null as the resolution value.

"calls the fulfillment callback" test

Since implementations like rsvp.js resolve asynchronously they are able to pass the test as it currently stands.When the test looks like this rsvp.js fails.

var p = fulfilled(sentinel)
setTimeout(function(){
  p.then(function (value) {
    assert.strictEqual(value, sentinel);
    done();
  });
}, 100)