Promise version of https://nicolas.perriault.net/code/2013/flatten-javascript-pyramids-with-async-js/

original.js

function load(fixtures, onComplete) {
    async.parallel(fixtures.map(function(fixture) {
        return function(cb) {
            store(fixture, function(err, result) {
                cb(err, result);
            });
        };
    }), onComplete);
}

describe("moods tests", function() {
    var moods = [
        "2013-02-01:n1k0:sunny"
      , "2013-02-02:n1k0:cloudy"
      , "2013-02-03:n1k0:stormy"
      , "2013-02-04:n1k0:rainy"
      // … we could add many more
    ];

    it ("should do something useful with moods", function(done) {
        load(moods, function(err, storedMoods) {
            done(err || undefined); // to make a fair comparison
        });
    });
});

withPromise.js

function load(fixtures) {
    return Q.all(fixtures.map(store)); // assumes the store function returns a promise for success
}

describe("moods tests", function() {
    var moods = [
        "2013-02-01:n1k0:sunny"
      , "2013-02-02:n1k0:cloudy"
      , "2013-02-03:n1k0:stormy"
      , "2013-02-04:n1k0:rainy"
      // … we could add many more
    ];
    // a promise-freindly test framework would expect promises to be returned
    it ("should do something useful with moods", function() {
        return load(moods);
    });
});

Yes, definitely interesting, though I can't see if mocha is promises-friendly yet. But it's certainly the future (haha, I couldn't resist).

Whether it's callbacks or promises, you have to embrace it entirely. Maybe Mocha won't ever be promise-friendly, but it wouldn't be hard to modify it for that purpose.

I thought once that promises imposed a perf burden because of the object allocations, but callback APIs need to allocate as much functions apparently, so even on that part.

Staring at the 2 snippets, I feel the callback version is more verbose because there is a lot of code aiming at passing result/errors manually. This code goes away with promises because this passing is built-in.

In the callback/promise debate, I was on the fence with a slight preference for promises. After this exercise and understanding why promise code is more readable, I'm definitely on the promise side now.

A thank you to tobie for a nice improvement on the promise snippet.

Maybe Mocha won't ever be promise-friendly, but it wouldn't be hard to modify it for that purpose.

https://gist.github.com/mjijackson/3956521 :)

OK, here's where all the war is at mochajs/mocha#329

UPDATE: the war has visibly been solved here http://chaijs.com/plugins/chai-as-promised ;)

Cool! This has definitely given me some incentive to look into promises some more. For what it's worth, I've done up how I would accomplish the snippet here https://gist.github.com/balupton/4714965 uses bal-util for flow and joe for testing. Feedback welcome.

For the records, Async.js ships with a native map method, not sure how I missed it :x

So the code is even shorter:

describe("moods tests", function() {
    var moods = [
        "2013-02-01:n1k0:sunny"
      , "2013-02-02:n1k0:cloudy"
      , "2013-02-03:n1k0:stormy"
      , "2013-02-04:n1k0:rainy"
      // … we could add many more
    ];

    it("should do something useful with moods", function(done) {
        async.map(moods, store, function(err, storedMoods) {
            assert.ifError(err);
            // now let's test stuff with stored moods
            done();
        });
    });
});

I could have kept the load() function in order to make the actual test code even shorter but I wouldn't really see the point.