chai-as-promised vs sinon-chai
JavaScript Testing Libraries Comparison
1 Year
chai-as-promisedsinon-chaiSimilar Packages:
What's JavaScript Testing Libraries?

Chai-as-promised and Sinon-Chai are both extensions of the Chai assertion library, each serving distinct purposes in the realm of JavaScript testing. Chai-as-promised is specifically designed to facilitate assertions on promises, allowing developers to write cleaner and more readable tests for asynchronous code. It enhances the expressiveness of tests by providing a fluent interface for handling promise resolutions and rejections. On the other hand, Sinon-Chai integrates Sinon.js with Chai, providing a set of assertions that work seamlessly with Sinon’s spies, mocks, and stubs. This combination allows developers to easily verify that functions were called as expected, enhancing the testing of side effects in code. Together, these libraries enrich the testing experience by offering specialized tools for different aspects of testing, particularly in asynchronous and behavior-driven development.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
chai-as-promised1,412,5491,42127.9 kB363 months agoMIT
sinon-chai912,2031,08916 kB197 months ago(BSD-2-Clause OR WTFPL)
Feature Comparison: chai-as-promised vs sinon-chai

Promise Assertions

  • chai-as-promised:

    Chai-as-promised provides a rich set of assertions specifically tailored for promises, allowing developers to assert on the eventual value or error of a promise. This includes methods like 'eventually' and 'finally', which enable chaining assertions that can handle both resolved and rejected states of promises in a clean and readable manner.

  • sinon-chai:

    Sinon-Chai does not provide promise-specific assertions but can be used in conjunction with other libraries to verify that promise-returning functions are called correctly. It focuses more on the behavior of functions rather than their promise states.

Integration with Sinon.js

  • chai-as-promised:

    Chai-as-promised does not integrate directly with Sinon.js, but it can be used alongside it for testing asynchronous code that involves spies or mocks. However, it does not provide specific assertions for Sinon’s features.

  • sinon-chai:

    Sinon-Chai is designed to work seamlessly with Sinon.js, providing assertions that enhance the capabilities of Sinon. This includes assertions like 'to.have.been.called' or 'to.have.been.calledWith', which allow developers to easily verify that mocked functions were called with the expected arguments.

Readability and Expressiveness

  • chai-as-promised:

    Chai-as-promised enhances the readability of tests involving promises by allowing developers to write assertions in a fluent, natural language style. This can make tests easier to understand and maintain, especially for those new to asynchronous programming.

  • sinon-chai:

    Sinon-Chai also promotes readability by allowing developers to write assertions that clearly express the expected behavior of functions. Its integration with Sinon.js means that tests can be more descriptive about how and when functions are called.

Error Handling

  • chai-as-promised:

    Chai-as-promised provides built-in support for asserting that promises reject with specific errors, making it easier to test error handling in asynchronous code. This is crucial for ensuring that applications behave correctly under failure conditions.

  • sinon-chai:

    Sinon-Chai does not focus on error handling related to promises, as its primary purpose is to verify function calls and interactions. It is more suited for testing synchronous behavior and side effects.

Community and Ecosystem

  • chai-as-promised:

    Chai-as-promised is widely used within the JavaScript community, especially in projects that utilize Chai for assertions. Its popularity ensures good documentation and community support, making it easier to find resources and examples.

  • sinon-chai:

    Sinon-Chai benefits from the strong community around Sinon.js, which is a well-established library for creating spies, mocks, and stubs. This integration allows developers to leverage a robust ecosystem for testing JavaScript applications.

How to Choose: chai-as-promised vs sinon-chai
  • chai-as-promised:

    Choose chai-as-promised if your project heavily relies on promises and you need a straightforward way to assert their outcomes in your tests. It is particularly useful for asynchronous testing scenarios where you want to ensure that promises resolve or reject as expected.

  • sinon-chai:

    Choose sinon-chai if you are utilizing Sinon.js for mocking and spying in your tests. It is ideal for projects that require detailed verification of function calls and interactions, allowing you to write more expressive assertions that complement Sinon’s capabilities.

README for chai-as-promised
Promises/A+ logo

Chai Assertions for Promises

Chai as Promised extends Chai with a fluent language for asserting facts about promises.

Instead of manually wiring up your expectations to a promise's fulfilled and rejected handlers:

doSomethingAsync().then(
    function (result) {
        result.should.equal("foo");
        done();
    },
    function (err) {
       done(err);
    }
);

you can write code that expresses what you really mean:

return doSomethingAsync().should.eventually.equal("foo");

or if you have a case where return is not preferable (e.g. style considerations) or not possible (e.g. the testing framework doesn't allow returning promises to signal asynchronous test completion), then you can use the following workaround (where done() is supplied by the test framework):

doSomethingAsync().should.eventually.equal("foo").notify(done);

Notice: either return or notify(done) must be used with promise assertions. This can be a slight departure from the existing format of assertions being used on a project or by a team. Those other assertions are likely synchronous and thus do not require special handling.

How to Use

should/expect Interface

The most powerful extension provided by Chai as Promised is the eventually property. With it, you can transform any existing Chai assertion into one that acts on a promise:

(2 + 2).should.equal(4);

// becomes
return Promise.resolve(2 + 2).should.eventually.equal(4);


expect({ foo: "bar" }).to.have.property("foo");

// becomes
return expect(Promise.resolve({ foo: "bar" })).to.eventually.have.property("foo");

There are also a few promise-specific extensions (with the usual expect equivalents also available):

return promise.should.be.fulfilled;
return promise.should.eventually.deep.equal("foo");
return promise.should.become("foo"); // same as `.eventually.deep.equal`
return promise.should.be.rejected;
return promise.should.be.rejectedWith(Error); // other variants of Chai's `throw` assertion work too.

assert Interface

As with the should/expect interface, Chai as Promised provides an eventually extender to chai.assert, allowing any existing Chai assertion to be used on a promise:

assert.equal(2 + 2, 4, "This had better be true");

// becomes
return assert.eventually.equal(Promise.resolve(2 + 2), 4, "This had better be true, eventually");

And there are, of course, promise-specific extensions:

return assert.isFulfilled(promise, "optional message");

return assert.becomes(promise, "foo", "optional message");
return assert.doesNotBecome(promise, "foo", "optional message");

return assert.isRejected(promise, Error, "optional message");
return assert.isRejected(promise, /error message regex matcher/, "optional message");
return assert.isRejected(promise, "substring to search error message for", "optional message");

Progress Callbacks

Chai as Promised does not have any intrinsic support for testing promise progress callbacks. The properties you would want to test are probably much better suited to a library like Sinon.JS, perhaps in conjunction with Sinon–Chai:

var progressSpy = sinon.spy();

return promise.then(null, null, progressSpy).then(function () {
    progressSpy.should.have.been.calledWith("33%");
    progressSpy.should.have.been.calledWith("67%");
    progressSpy.should.have.been.calledThrice;
});

Customizing Output Promises

By default, the promises returned by Chai as Promised's assertions are regular Chai assertion objects, extended with a single then method derived from the input promise. To change this behavior, for instance to output a promise with more useful sugar methods such as are found in most promise libraries, you can override chaiAsPromised.transferPromiseness. Here's an example that transfer's Q's finally and done methods:

import {setTransferPromiseness} from 'chai-as-promised';

setTransferPromiseness(function (assertion, promise) {
    assertion.then = promise.then.bind(promise); // this is all you get by default
    assertion.finally = promise.finally.bind(promise);
    assertion.done = promise.done.bind(promise);
});

Transforming Arguments to the Asserters

Another advanced customization hook Chai as Promised allows is if you want to transform the arguments to the asserters, possibly asynchronously. Here is a toy example:

import {transformAsserterArgs} from 'chai-as-promised';

setTransformAsserterArgs(function (args) {
    return args.map(function (x) { return x + 1; });
});

Promise.resolve(2).should.eventually.equal(2); // will now fail!
Promise.resolve(3).should.eventually.equal(2); // will now pass!

The transform can even be asynchronous, returning a promise for an array instead of an array directly. An example of that might be using Promise.all so that an array of promises becomes a promise for an array. If you do that, then you can compare promises against other promises using the asserters:

// This will normally fail, since within() only works on numbers.
Promise.resolve(2).should.eventually.be.within(Promise.resolve(1), Promise.resolve(6));

setTransformAsserterArgs(function (args) {
    return Promise.all(args);
});

// But now it will pass, since we transformed the array of promises for numbers into
// (a promise for) an array of numbers
Promise.resolve(2).should.eventually.be.within(Promise.resolve(1), Promise.resolve(6));

Compatibility

Chai as Promised is compatible with all promises following the Promises/A+ specification.

Notably, jQuery's promises were not up to spec before jQuery 3.0, and Chai as Promised will not work with them. In particular, Chai as Promised makes extensive use of the standard transformation behavior of then, which jQuery<3.0 does not support.

Angular promises have a special digest cycle for their processing, and need extra setup code to work with Chai as Promised.

Working with Non-Promise–Friendly Test Runners

Some test runners (e.g. Jasmine, QUnit, or tap/tape) do not have the ability to use the returned promise to signal asynchronous test completion. If possible, I'd recommend switching to ones that do, such as Mocha, Buster, or blue-tape. But if that's not an option, Chai as Promised still has you covered. As long as your test framework takes a callback indicating when the asynchronous test run is over, Chai as Promised can adapt to that situation with its notify method, like so:

it("should be fulfilled", function (done) {
    promise.should.be.fulfilled.and.notify(done);
});

it("should be rejected", function (done) {
    otherPromise.should.be.rejected.and.notify(done);
});

In these examples, if the conditions are not met, the test runner will receive an error of the form "expected promise to be fulfilled but it was rejected with [Error: error message]", or "expected promise to be rejected but it was fulfilled."

There's another form of notify which is useful in certain situations, like doing assertions after a promise is complete. For example:

it("should change the state", function (done) {
    otherState.should.equal("before");
    promise.should.be.fulfilled.then(function () {
        otherState.should.equal("after");
    }).should.notify(done);
});

Notice how .notify(done) is hanging directly off of .should, instead of appearing after a promise assertion. This indicates to Chai as Promised that it should pass fulfillment or rejection directly through to the testing framework. Thus, the above code will fail with a Chai as Promised error ("expected promise to be fulfilled…") if promise is rejected, but will fail with a simple Chai error (expected "before" to equal "after") if otherState does not change.

Working with async/await and Promise-Friendly Test Runners

Since any assertion that must wait on a promise returns a promise itself, if you're able to use async/await and your test runner supports returning a promise from test methods, you can await assertions in tests. In many cases you can avoid using Chai as Promised at all by performing a synchronous assertion after an await, but awaiting rejectedWith is often more convenient than using try/catch blocks without Chai as Promised:

it('should work well with async/await', async () => {
  (await Promise.resolve(42)).should.equal(42)
  await Promise.reject(new Error()).should.be.rejectedWith(Error);
});

Multiple Promise Assertions

To perform assertions on multiple promises, use Promise.all to combine multiple Chai as Promised assertions:

it("should all be well", function () {
    return Promise.all([
        promiseA.should.become("happy"),
        promiseB.should.eventually.have.property("fun times"),
        promiseC.should.be.rejectedWith(TypeError, "only joyful types are allowed")
    ]);
});

This will pass any failures of the individual promise assertions up to the test framework, instead of wrapping them in an "expected promise to be fulfilled…" message as would happen if you did return Promise.all([…]).should.be.fulfilled. If you can't use return, then use .should.notify(done), similar to the previous examples.

Installation and Setup

Node

Do an npm install chai-as-promised to get up and running. Then:

import * as chai from 'chai';
import chaiAsPromised from 'chai-as-promised';

chai.use(chaiAsPromised);

// Then either:
const expect = chai.expect;
// or:
const assert = chai.assert;
// or:
chai.should();
// according to your preference of assertion style

You can of course put this code in a common test fixture file; for an example using Mocha, see the Chai as Promised tests themselves.

Note when using other Chai plugins: Chai as Promised finds all currently-registered asserters and promisifies them, at the time it is installed. Thus, you should install Chai as Promised last, after any other Chai plugins, if you expect their asserters to be promisified.

Karma

If you're using Karma, check out the accompanying karma-chai-as-promised plugin.

Browser/Node Compatibility

Chai as Promised requires support for ES modules and modern JavaScript syntax. If your browser doesn't support this, you will need to transpile it down using a tool like Babel.