How to test promise rejection with Mocha and Chai in Node? - node.js

I am trying to test my services and dao using Mocha and Chai. But, in Istanbul coverage, I am getting the 'reject' lines as red. Here is the code for a sample testing method.
describe('findAllCategories()', function() {
it('should return all categories', function() {
var stub = sinon.stub(categoryDao, 'findAllCategories');
stub.callsFake(() => {
return Promise.resolve(cat);
});
categoryService.findAllCategories().then(response => {
assert.length(response, 1);
}).catch(isError)
.then((err) => {
console.log(err);
assert.isDefined(err);
});
})
});
Now, when I'm logging the error, it is showing "TypeError: assert.length is not a function".
Any way out?

The assert-library does not have a function length, but instead you can use lengthOf() (see https://www.chaijs.com/api/assert/ for more information):
assert.lengthOf(response, 1);

Related

Testing synchronous code

I have a section of code that is using node-sync like so:
function funcA() {
return new Promise(function(resolve, reject) {
Sync(function () {
return funcB.sync();
}, function (err, result) {
if(err) {
reject(err);
} else {
resolve(result);
}
});
}
This code is tested using mocha+chai:
it("should return array", function() {
return funcA().then(function(result) {
expect(result).to.be.an.instanceof(Array);
});
});
It worked just fine couple of months ago, but now this test always times out:
Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.
What I've tried so far:
using done() instead of returning a promise
replacing node-sync with synchronize.js
increasing timeout
What I found out, is that expect(... part of this test is, in fact, being called, but only after mocha kills the test. No matter what timeout interval is currently set, expect(.. is being called always ~20 milliseconds after I get Error: timeout message.
I fixed the issue by adding setInterval(function(){}, 10) on the top of the test file. I'd like to know why this worked and if there is some better way to fix that?
[EDIT] It looks like this is a node-version specific issue. Test fails on 0.12.4 but runs correctly on 0.10.38 .
[EDIT] Actual code is available here.
Based on your code, I am assuming that your funcB function is running code in a synchronous way.
So when I create funcB in this way:
function funcB() {
return [1, 2, 3];
}
And run the test, Mocha shows an error:
Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.
But if I convert the funcB in asynchronus function as this:
function funcB(cb) {
process.nextTick(function () {
cb(null, [1, 2, 3]);
});
}
Mocha runs the test without any problem:
✓ should return an array
So my complete code that runs ok (the funcB commented is the one that will cause the error) is this:
// install dependencies
// npm install promise
// npm install sync
var Promise = require('promise');
var assert = require('assert');
var Sync = require('sync');
function funcA() {
return new Promise(function (resolve, reject) {
Sync(function () {
return funcB.sync();
}, function (err, result) {
if (err) {
reject(err);
} else {
resolve(result);
}
});
});
}
// function funcB() {
// return [1, 2, 3];
// }
function funcB(cb) {
process.nextTick(function () {
cb(null, [1, 2, 3]);
});
}
it("should return an array", function(done) {
return funcA().then(
function (result) {
console.log(result);
assert.equal(Array.isArray(result), true);
done();
}
);
});
So I am opinion I think that the misuse of the sync method (using it on synchronous functions) created by sync library is the one that is causing this problem.
You may just be missing the done() callback:
it("should return array", function(done) {
funcA().then(function(result) {
expect(result).to.be.an.instanceof(Array);
done();
});
});
http://mochajs.org/#asynchronous-code
You can use a timeout parameter for mocha executable.
For example, if you want a 500 milliseconds timeout, just change your package.json to:
"scripts": {
"test": "mocha specs --timeout 500 --require specs/helpers/chai.js"
},
And maybe your promise is being rejected, so you have to call done using catch method.
it("should return array", function(done) {
return funcA().then(function(result) {
expect(result).to.be.an.instanceof(Array);
done();
}).catch(done);
});
This would also help you debug eventual errors that might happen in your promise code.

How do I properly test promises with mocha and chai?

The following test is behaving oddly:
it('Should return the exchange rates for btc_ltc', function(done) {
var pair = 'btc_ltc';
shapeshift.getRate(pair)
.then(function(data){
expect(data.pair).to.equal(pair);
expect(data.rate).to.have.length(400);
done();
})
.catch(function(err){
//this should really be `.catch` for a failed request, but
//instead it looks like chai is picking this up when a test fails
done(err);
})
});
How should I properly handle a rejected promise (and test it)?
How should I properly handle a failed test (ie: expect(data.rate).to.have.length(400);?
Here is the implementation I'm testing:
var requestp = require('request-promise');
var shapeshift = module.exports = {};
var url = 'http://shapeshift.io';
shapeshift.getRate = function(pair){
return requestp({
url: url + '/rate/' + pair,
json: true
});
};
The easiest thing to do would be to use the built in promises support Mocha has in recent versions:
it('Should return the exchange rates for btc_ltc', function() { // no done
var pair = 'btc_ltc';
// note the return
return shapeshift.getRate(pair).then(function(data){
expect(data.pair).to.equal(pair);
expect(data.rate).to.have.length(400);
});// no catch, it'll figure it out since the promise is rejected
});
Or with modern Node and async/await:
it('Should return the exchange rates for btc_ltc', async () => { // no done
const pair = 'btc_ltc';
const data = await shapeshift.getRate(pair);
expect(data.pair).to.equal(pair);
expect(data.rate).to.have.length(400);
});
Since this approach is promises end to end it is easier to test and you won't have to think about the strange cases you're thinking about like the odd done() calls everywhere.
This is an advantage Mocha has over other libraries like Jasmine at the moment. You might also want to check Chai As Promised which would make it even easier (no .then) but personally I prefer the clarity and simplicity of the current version
As already pointed out here, the newer versions of Mocha are already Promise-aware. But since the OP asked specifically about Chai, it's only fair to point out the chai-as-promised package which provides a clean syntax for testing promises:
using chai-as-promised
Here's how you can use chai-as-promised to test both resolve and reject cases for a Promise:
var chai = require('chai');
var expect = chai.expect;
var chaiAsPromised = require("chai-as-promised");
chai.use(chaiAsPromised);
...
it('resolves as promised', function() {
return expect(Promise.resolve('woof')).to.eventually.equal('woof');
});
it('rejects as promised', function() {
return expect(Promise.reject('caw')).to.be.rejectedWith('caw');
});
without chai-as-promised
To make it really clear as to what's getting tested, here's the same example coded without chai-as-promised:
it('resolves as promised', function() {
return Promise.resolve("woof")
.then(function(m) { expect(m).to.equal('woof'); })
.catch(function(m) { throw new Error('was not supposed to fail'); })
;
});
it('rejects as promised', function() {
return Promise.reject("caw")
.then(function(m) { throw new Error('was not supposed to succeed'); })
.catch(function(m) { expect(m).to.equal('caw'); })
;
});
Here's my take:
using async/await
not needing extra chai modules
avoiding the catch issue, #TheCrazyProgrammer pointed out above
A delayed promise function, that fails, if given a delay of 0:
const timeoutPromise = (time) => {
return new Promise((resolve, reject) => {
if (time === 0)
reject({ 'message': 'invalid time 0' })
setTimeout(() => resolve('done', time))
})
}
// ↓ ↓ ↓
it('promise selftest', async () => {
// positive test
let r = await timeoutPromise(500)
assert.equal(r, 'done')
// negative test
try {
await timeoutPromise(0)
// a failing assert here is a bad idea, since it would lead into the catch clause…
} catch (err) {
// optional, check for specific error (or error.type, error. message to contain …)
assert.deepEqual(err, { 'message': 'invalid time 0' })
return // this is important
}
assert.isOk(false, 'timeOut must throw')
log('last')
})
Positive test is rather simple. Unexpected failure (simulate by 500→0) will fail the test automatically, as rejected promise escalates.
Negative test uses the try-catch-idea. However: 'complaining' about an undesired pass happens only after the catch clause (that way, it does not end up in the catch() clause, triggering further but misleading errors.
For this strategy to work, one must return the test from the catch clause. If you want't to test anything else, use another it()-block.
Thre is a better solution. Just return the error with done in a catch block.
// ...
it('fail', (done) => {
// any async call that will return a Promise
ajaxJson({})
.then((req) => {
expect(1).to.equal(11); //this will throw a error
done(); //this will resove the test if there is no error
}).catch((e) => {
done(e); //this will catch the thrown error
});
});
this test will fail with following message: AssertionError: expected 1 to equal 11

How to test stubbed database queries

I have a Sails.Js controller that looks like this
module.exports = {
confirmID: function(req,res) {
var uid = req.params.id;
User.findOne({id:uid}).exec(function(err,user) {
// ...
});
}
}
where User is a sails-postgres model. I have tried testing it with mocha, sinon and supertest with a test like this
describe('Controller', function() {
var sandbox;
before(function() {
sandbox = sinon.sandbox.create();
sandbox.stub(User, 'findOne');
});
after(function() {
sandbox.restore();
});
describe('GET /confirmid/:id', function() {
it('should do something', function(done) {
request(sails.hooks.http.app)
.get('/confirmid/123')
.expect(200)
.end(function(err,res) {
sandbox.fakes[0].called.should.be.true;
done();
});
});
});
If I leave it at that it errors out because exec is called on undefined, but I can't seem to stub the nested exec method without either errors or the test hanging. Is there a way to stub a series of method calls such as .find().exec()? Or am I best to just leave this to integration tests where I can test it with an actual database?
Assuming that you really want to stub (not just spy) - you want to control what the query resolves to as opposed to simply knowing whether the query was executed. Here's what I'm using to stub sails/waterline query methods. Something like...
var stubQueryMethod = require('stubQueryMethod');
describe('Controller', function() {
before(function() {
stubQueryMethod(User, 'findOne', {
id: 123,
name: 'Fred Fakes'
});
});
after(function() {
User.findOne.restore();
});
describe('GET /confirmid/:id', function() {
it('should do something', function(done) {
request(sails.hooks.http.app)
.get('/confirmid/123')
.expect(200)
.end(function(err,user) {
user.should.have.property('name', 'Fred Fakes');
done();
});
});
});
});
Source: https://gist.github.com/wxactly/f2258078d802923a1a0d
For people looking for other options to stub or mock waterline models, I've found the following four options:
stubQueryMethod.js gist - https://gist.github.com/wxactly/f2258078d802923a1a0d
model mock gist - https://gist.github.com/campbellwmorgan/e305cc36365fa2d052a7
weaselpecker - https://github.com/ottogiron/weaselpecker
sails-mock-models - https://github.com/ryanwilliamquinn/sails-mock-models
After evaluating each one, I've decided on sails-mock-models because it is easy to understand and seems the most used sails mocking library according to npm: https://www.npmjs.com/package/sails-mock-models
Hope this helps someone!
Update: I'm still using sails-mock-models, and it is quite easy, but there are a few drawbacks such as it fails to return promises that are taken into a q.all(promiseArray).then() call. If I get around to investigating the other options or find a workaround, I will post it here.
This will only work for queries that use exec and it overloads all exec calls so if you try to return an error and you have, say, a controller with a policy out front, and the policy does a database lookup, you'll likely go into error there prior to hitting the controller code you intended to test.... that can be fixed with stub.onCall(x), but it is still a bit precarious.
Warnings aside, here's how I've done this in the past:
var path = require('path');
var sinon = require('sinon');
var Deferred = require(path.join(
process.cwd(),
'node_modules/sails',
'node_modules/waterline',
'lib/waterline/query/deferred'
));
module.exports = function () {
return sinon.stub(Deferred.prototype, 'exec');
};
Assuming you have the following service, MyService:
module.exports.dbCall = function (id, cb) {
Model.findOne(id).exec(function (err, result) {
if (err) {
sails.log.error('db calls suck, man');
return cb(err, null);
}
cb(null, result);
});
};
You can test the error case like so:
before(function () {
stub = databaseStub();
});
afterEach(function () {
stub.reset();
});
after(function () {
stub.restore();
});
it('should return errors', function (done) {
stub.onCall(0).callsArgWith(0, 'error');
MyService.dbCall(1, function (err, results) {
assert.equal(err, 'error');
assert.equal(results, null);
done();
});
});

How to make assertions inside a promise when any errors thrown don't bubble up?

Running this with mocha results in timing out, rather than letting mocha catch the error so it could fail immediately..
var when = require('when');
var should = require('should');
describe('', function() {
it('', function(done) {
var d = when.defer();
d.resolve();
d.promise.then(function() {
true.should.be.false;
false.should.be.true;
throw new Error('Promise');
done();
}); }); });
http://runnable.com/me/U7VmuQurokZCvomD
Is there another way to make assertions inside the promise, such that when they fail they are caught by mocha causing it to fail immediately?
As per chai recommendation, I looked into it and it seems I have to have a direct access to the promise object, right? The problem is that I'm not using promise directly.. My bad if I simplified but This would be a more closer to reality example
function core_library_function(callback){
do_something_async(function which_returns_a(promise){
promise.then(function(){
callback(thing);
}); }); }
describe('', function() {
it('', function(done) {
core_library_function(function(thing){
...
done();
}); }); });
So I really have no control over the promise directly, it's abstracted far far away.
When using promises with Mocha, you'll have to return the promise in the test and will want to remove the done parameter since the callback isn't being used.
it('', function() {
var d = when.defer();
d.resolve();
return d.promise.then(function() {
throw new Error('Promise');
});
});
This is described in the docs under Working with Promises:
Alternately, instead of using the done() callback, you can return a promise.

mocha times out on failed assertions with Q promises

Why does mocha timeout when an assertion fails inside a Q future? You also don't get to see the assertion failure when this happens. This does not happen if I just use callbacks. How should I write this while still using futures but get to see the assertion error instead of a timeout?
var Q = require('q');
function hack() {
var ret = Q.defer();
ret.resolve(true);
return ret.promise;
}
it('test', function(done) {
hack().then(function(bool) {
assert(false);
done();
});
});
The assertion call throws an exception, which is caught by Q in order to properly conform to the promises spec. So mocha never reaches done(), nor does it see an exception thrown. You could do something like this:
it('test', function(done) {
hack().then(function(bool) {
assert(false);
done();
}).catch(function(err){
done(err);
});
});
[edit] Alternatively, you can omit the done argument altogether and just return the promise directly from the test function, in which case mocha will pass/fail the test based on the outcome of the returned promise:
it('test', function() {
return hack().then(function(bool) {
assert(false);
});
});
...which is a nice way to simplify your test functions. Props to Taytay elsewhere in this thread for pointing this out.
Mocha now supports promises in unit tests, so you can just return the promise instead of relying upon calling (done) from a then handler. It's easier and safer (because you won't forget to call done)
So you could just write:
it('test', function() {
return hack().then(function(bool) {
assert(false);
});
});
That would fail because the promise would fail, and Mocha would detect it.
This is from the Mocha docs in the section "Working with Promises": https://mochajs.org/
Improving on greim's answer including what callumacrae added in a comment, you can do it like this:
it('test', function(done) {
hack().then(function(bool) {
assert(false);
done();
}).catch(done);
});

Resources