Add support for promise-returning tests #202

Closed
wants to merge 1 commit into from

8 participants

@kriskowal

This patch makes it possible for it blocks to return promises for their results, obviating the need for waitsFor blocks. Particularly, this supports jQuery, Dojo, and Q style promises.

var Q = require("q");
describe("Q.delay", function () {
    it("can time out", function () {
        return Q.delay(1000).timeout(500)
        .then(function (value) { // fulfillment callback
            expect(true).toBe(false); // should not get here
        }, function (error) {
            expect(error).toBe("Timed out");
        });
    });
});
@domenic

Notably, with appropriate plugins to assertion libraries (coming soon for Chai!), you can get stuff like

var Q = require("q");
describe("Q.delay", function () {
    it("can time out", function () {
        return Q.delay(1000).timeout(500).should.be.rejectedWith("Timed out");
    });
});
@ragaskar

The idea seems sound, but this commit needs to add some tests before we'd be able to merge it.

Thanks!

@kriskowal

Awesome. I’ll make this happen.

@kriskowal

@ragaskar Tests included. Thanks!

@kriskowal

@domenic I bet we could obviate the need for the return. Consider, in Jasmine’s parlance:

expect(aPromise).toBeFulfilled().toEqual(10);
expect(bPromise).toBeRejectedWith("Timed out");

Or some such equivalent sugar. The trick is for toBeFulfilled or toBeRejected or toBeResolved to enqueue a task to the current spec that waits for the resolution of the promise before completing.

@nonplus

@kriskowal, the return is necessary, since it'll allow the asserts to be independent of the runtime environment. IMO, you don't want to couple Chai's implementation with Jasmine's. I want to be able to use the same asserts in Mocha (using @domenic's fork [https://github.com/visionmedia/mocha/pull/329/commits]).

@domenic

BTW a progress update on my as-yet-unpublished Chai plugin: so far I have

promise.should.be.fulfilled
promise.should.be.rejected
promise.should.be.rejected.with(TypeError)
promise.should.be.rejected.with(TypeError, "message substring")
promise.should.be.rejected.with("message substring")
promise.should.be.rejected.with(TypeError, /message matcher/)
promise.should.be.rejected.with(/message matcher/)

as well as negated versions of all these (promise.should.not.be.fulfilled etc.)

The next big thing will be adding promise.should.eventually.eql(5), promise.should.eventually.contain(6), etc., i.e. adding an eventually extender that allows you to use normal Chai assertions on the promise's fulfillment value.

@nonplus

@domenic, what are the assert equivalents going to be called? Simply fulfilled, isFullfiled, getsFulfilled or something else?

I'm asking because I'd like to use the same signature in our asserts so that we can drop in your implementation once it's public.

Also, in the assert style, it's useful for the /message matcher/ to optionally take a callback in which you could then do the eventual asserts.

@domenic

Announcing: Chai as Promised!

@nonplus I haven't given that much thought, as I don't use the assert style myself. But I'd be happy to add it! Perhaps we should take this discussion to the Chai mailing list.

@kriskowal

@ragaskar I’ve added tests. Please let me know if the pull needs further refinement before you can accept it.

@loganfsmyth

Hey all, I was wondering what the status was on this. Are you guys just busy or are there things that need to be addressed. This would be an excellent addition I think. I'm happy to help.

@ragaskar

Our main jasmine-core focus right now is on a pretty big factor that should make it easier for people to contribute to and extend jasmine. Happily, one of these things is a better approach to async -- while it doesn't look quite like the syntax proposed here, I think you'll be quite happy with it. If you want a sneak peek you can look at the 2_0 branch (https://github.com/pivotal/jasmine/commits/2_0, specifically this commit: a526ebf).

Thanks!

@loganfsmyth

Cool, thanks for replying so quickly! I'll take a look.

@logankd logankd referenced this pull request in velesin/jasmine-jquery Apr 3, 2013
Closed

Support jQuery Promises #121

@infews

Are people looking at master? Does the Mocha-inspired async syntax work for you?

@felixjendrusch

I'm using this for now.

@slackersoft
Jasmine member

In 2.0, its can receive a done callback to invoke when they have completed asynchronous tests, which should solve this issue. Closing for now, please take a look and if this doesn't cover your use case, please re-open or create a new pull on top of master.

@slackersoft slackersoft closed this Oct 2, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment