I am dealing with a code mixing node-style callbacks and Bluebird promises, and I need to write some unit tests for it.
In particular, cache.js exposes the init() function, which works with promises. It is then called by the doSomething() function in another file (e.g. index.js) which in turn accepts a callback that has to be invoked at the end of init().
Pseudocode is as follows:
// [ cache.js ]
function init() {
return performInitialisation()
.then((result) => return result);
}
// [ index.js ]
var cache = require('./cache');
function doSomething(callback) {
console.log('Enter');
cache.init()
.then(() => {
console.log('Invoking callback');
callback(null);
})
.catch((err) => {
console.log('Invoking callback with error');
callback(err);
});
console.log('Exit');
}
A possible unit test could be (showing only relevant code):
// [ index.test.js ]
...
var mockCache = sinon.mock(cache);
...
it('calls the callback on success', function(done) {
mockCache.expects('init')
.resolves({});
var callback = sinon.spy();
doSomething(callback);
expect(callback).to.have.been.calledOnce;
done();
});
This test passes, however changing the expectation to not.have.been.calledOnce also passes, which is wrong.
Also, console logs are out of sequence:
Enter
Exit
Invoking callback
I have looked at several possibilities, none of which worked:
Using chai-as-promised, e.g. expect(callback).to.eventually.have.been.calledOnce;
Refactoring doSomething() to be simply:
function doSomething(callback) {
cache.init()
.asCallback(callback);
}
Can anyone help me understand what I am doing wrong and how I can fix it please?
console logs are out of sequence
The logs are in the correct order because your Promise will be async meaning, at the very least, the internal console logs calls in then & catch will run on the next tick.
As to why the test is failing is the result of a couple of issues, first one is you don't appear to have sinon-chai configured correctly, or at best your calledOnce assertion isn't kicking in. Just to confirm, the top of your test file should something like:
const chai = require("chai");
const sinonChai = require("sinon-chai");
chai.use(sinonChai);
If you have that and it's still not working correctly then might be worth opening an issue on the sinon-chai lib, however, a simple workaround is to switch to sinon assertions e.g.
sinon.assert.calledOnce(callback)
Secondly, when you do eventually fix this, you'll probably find that the test will now fail...everytime. Reason being you've got the same problem in your test that you have with your logging - your asserting before the internal promise has had a chance to resolve. Simplest way of fixing this is actually using your done handler from Mocha as your assertion
mockCache.expects('init').resolves({});
doSomething(() => done());
In other words, if done get's called then you know the callback has been called :)
Following James' comment I revisited my tests like this:
it('calls the callback on success', function(done) {
mockCache.expects('init')
.resolves({});
doSomething(done);
});
it('calls the callback on error', function(done) {
mockCache.expects('init')
.rejects('Error');
doSomething((err) => {
if (err === 'Error') {
done();
} else {
done(err);
}
});
});
Related
I'm starting to test my code with Jest, and I can't make a seemingly simple test to pass. I am simply trying to check if what I receive from a Maogoose database request is an object.
The function fetchPosts() is working because I hooked it up with a React frontend and it is displaying the data correctly.
This is my function fetchPosts():
module.exports = {
fetchPosts() {
return new Promise((resolve, reject) => {
Posts.find({}).then(posts => {
if (posts) {
resolve(posts)
} else {
reject()
}
})
})
}
}
And my test:
it('should get a list of posts', function() {
return posts.fetchPosts().then(result => {
expect(typeof result).toBe('object')
})
})
This makes the test fail, and Jest says
'Timeout - Async callback was not invoked within the 5000ms timeout specified by jest.setTimeout.'
QUESTION: How can I make this test pass?
You can expect asynchronous results using resolves, as shown in the Jest documentation.
In your case:
it('should get a list of posts', function() {
const result = posts.fetchPosts();
expect(result).resolves.toEqual(expect.any(Object));
})
…although I have a suspicion your list of posts is actually an array, so you probably want this:
it('should get a list of posts', function() {
const result = posts.fetchPosts();
expect(result).resolves.toEqual(expect.any(Array));
})
Another tip: You don't need to wrap the body of your fetchPost in an additional promise, you can simply return the promise you get from Posts.find and add a then to it, like this:
module.exports = {
fetchPosts() {
return Posts.find({}).then(posts => {
if (posts) {
return posts;
}
throw new Error('no posts'); // this will cause a promise rejection
})
}
}
It's also highly possible that you're not getting a response back from the DB at all from your test suite. Test suite's can call different environmental variables / configs that lead to different calls. This error can also be seen if no response is returned, as in - if someone blocks your IP from connecting, on and on.
Also if you are simply looking to increase the timeout, then you can do that by setting
jest.setTimeout(10000);
You can use this statement in beforeEach if you want to change the timeout for all your tests in that describe block or in the test/it/spec block if you want it for a single test.
For me none of the above worked so I tried older version of jest and it worked
npm i -D jest#25.2.7.
if you are using it with typescript make sure to degrade ts-jest as well
npm i -D jest#25.2.7 ts-jest#25.3.1
Im trying to unit test a function that calls a promise...
Using Mocha, Sinon. I have a functional block like this:
myfile.js:
let OuterDependecy = require('mydep');
function TestFunction(callback) {
OuterDependency.PromiseFunction().then(response => {
//some logic here
}).catch(err => {callback(err)});
inside my test i have used proxyquire to mock the outerdependecy
testfile.js
let proxyquire = require('proxyquire');
let OuterDepStub = {};
let testingFunc = proxyquire('myfile.js', {'mydep': OuterDepStub});
... then inside my testing block
let stubCallback = function() {
console.log('Stub dubadub dub'); //note...i can use sinon.spy here instead
};
beforeEach(()=>{
OuterDependency.PromiseFunction = function(arg) {
return new Promise((resolve, reject)=>{
reject('BAD');
});
};
spy = sinon.spy(stubCallback);
});
my actual test now calls the main "testfunction"
it('Catches Errors, and calls back using error', done => {
TestFunction(stubCallback);
expect(spy).to.have.been.called;
done();
});
I see the stub being called (the console log, hence why i didnt want to use sinon.spy) but the spy is saying its not called. and unit test fails.
I believe this is probably due to a race condition of sorts where the promise is resolving after my test is run... is there anyway to delay the test until my promise is resolve.
i know in in angularjs promise testing, there was a way to "tick" the promise so it resolves when you want to. possible in nodejs?
is there anyway to delay the test until my promise is resolve.
As far as I understand your issue, yes, you should only call done() after the promise is settled. In order to do that,you need two things:
1- Enforce TestFunction to return a Promise, so you can wait until it resolves:
function TestFunction(callback) {
return OuterDependency.PromiseFunction().then(response => {
//some logic here
}).catch(err => { callback(err) });
}
2- Wait to that promise to settle, then call done.
it('Catches Errors, and calls back using error', done => {
TestFunction(stubCallback).then(() => {
expect(spy).to.have.been.called;
done();
})
});
now, our then block won't run until the catch block within TestFunction, so if the test works as expected (i.e. the catch block fires and the callback gets fired), the expectation and the done calls will always fire after the callback gets called.
I see the stub being called (the console log, hence why i didnt want to use sinon.spy) but the spy is saying its not called. and unit test fails.
That's because your expectation runs right after the TestFunction calls, without waiting for it to settle. However, it will get called lately, thus the console.log appears in the next spec.
A typical test in my node.js mocha suite looks like the following:
it("; client should do something", function(done) {
var doneFn = function(args) {
// run a bunch of asserts on args
client.events.removeListener(client.events.someEvent, userMuteFn);
done();
}
client.events.on(someEvent, doneFn);
client.triggerEvent();
});
The problem here is that if client.triggerEvent() doesn't do something right, or if the server breaks and never invokes someEvent, then done() will never get invoked. This leaves an ambiguous error for someone who hasn't worked with the testsuite before like:
Error: timeout of 10500ms exceeded. Ensure the done() callback is being called in this test.
My question is, is there a way to rewrite these tests, whether it's with mocha or in addition to another lib, that makes async work like this easier to follow. I'd love to be able to output something such as:
the callback doneFn() was never invoked after clients.event.on(...) was invoked
or perhaps something similar.
I'm not sure if using something such as promises would help this. More meaningful error messages for async/callback type code would be a great thing. If it means moving from callback/async to another workflow, I'm OK with that as well.
What are some solutions?
When you get a timeout error rather than a more precise error, the first thing to do is to check that your code does not swallow exceptions, and that it does not swallow promise rejections. Mocha is designed to detect these in your tests. Unless you do something unusual like running test code in your own VM or manipulate domains, Mocha will detect such failures, but if your code swallows them, there's nothing Mocha can do.
This being said, Mocha won't be able to tell you that done was not called because your implementation has a logic bug that causes it to fail to call the callback.
Here is what could be done with sinon to perform a post mortem after test failures. Let me stress that this is a proof of concept. If I wanted to use this on an ongoing basis, I'd develop a proper library.
var sinon = require("sinon");
var assert = require("assert");
// MyEmitter is just some code to test, created for the purpose of
// illustration.
var MyEmitter = require("./MyEmitter");
var emitter = new MyEmitter();
var postMortem;
beforeEach(function () {
postMortem = {
calledOnce: []
};
});
afterEach(function () {
// We perform the post mortem only if the test failed to run properly.
if (this.currentTest.state === "failed") {
postMortem.calledOnce.forEach(function (fn) {
if (!fn.calledOnce) {
// I'm not raising an exception here because it would cause further
// tests to be skipped by Mocha. Raising an exception in a hook is
// interpreted as "the test suite is broken" rather than "a test
// failed".
console.log("was not called once");
}
});
}
});
it("client should do something", function(done) {
var doneFn = function(args) {
// If you change this to false Mocha will give you a useful error. This is
// *not* due to the use of sinon. It is wholly due to the fact that
// `MyEmitter` does not swallow exceptions.
assert(true);
done();
};
// We create and register our spy so that we can conduct a post mortem if the
// test fails.
var spy = sinon.spy(doneFn);
postMortem.calledOnce.push(spy);
emitter.on("foo", spy);
emitter.triggerEvent("foo");
});
Here is the code of MyEmitter.js:
var EventEmitter = require("events");
function MyEmitter() {
EventEmitter.call(this);
}
MyEmitter.prototype = Object.create(EventEmitter.prototype);
MyEmitter.prototype.constructor = MyEmitter;
MyEmitter.prototype.triggerEvent = function (event) {
setTimeout(this.emit.bind(this, event), 1000);
};
module.exports = MyEmitter;
You should to listen to uncaughtException events, in addition to someEvent. This way you'll catch errors happening in client, and those will show up in your test report.
it("; client should do something", function(done) {
var doneFn = function(args) {
// run a bunch of asserts on args
client.events.removeListener(client.events.someEvent, userMuteFn);
done();
}
var failedFn = function(err) {
client.events.removeListener('uncaughtException', failedFn);
// propagate client error
done(err);
}
client.events.on(someEvent, doneFn);
client.events.on('uncaughtException', failedFn);
client.triggerEvent();
});
P.S. In case client is a child process, you also should listen to exit event, which will be triggered in case the child process dies.
I have this kind of a mocha test:
describe 'sabah', →
beforeEach →
#sabahStrategy = _.filter(#strats, { name: 'sabah2' })[0]
.strat
it 'article list should be populated', (done) →
#timeout 10000
strat = new #sabahStrategy()
articles = strat.getArticleStream('barlas')
articles.take(2).toArray( (result)→
_.each(result, (articleList) →
// I make the assertions here
// assert(false)
assert(articleList.length > 1)
)
done()
)
The problem is, whenever I do assert(false), the test hangs until the timeout, instead of giving an assertion error, why?
Edit:
For example if I have these two tests
it 'assert false', (done) →
assert(false)
done()
it 'article link stream should be populated', (done) →
#timeout 20000
articles = #sabahStrategy.articleLinkStream('barlas')
articles.pull((err, result)→
console.log('here')
assert(false)
console.log('after')
assert(!err)
assert(result.length > 1);
_.each(result, (articleList) →
assert(articleList.link)
)
done()
)
The first one, gives the assertion error as expected, the second one, logs here, and hangs at assert(false) so after is never logged. It has something to do with articles being a stream and the assertion is within a pull callback, this is from the highland.js API.
Solved Edit:
So according to Paul I fixed the problem with this code:
it 'article stream should be populated', (done) →
#timeout 30000
articles = #sabahStrategy.articleStream('barlas')
articles.pull((err, result) →
try
# assert false properly throws now.
assert(false)
assert(!err)
assert(result.length == 1)
assert(result[0].body)
assert(result[0].title || result[0].title2)
done()
catch e
done(e)
)
Edit2:
I've produced a simplified version of the problem:
h = require('highland')
Q = require('q')
describe 'testasynchigh', →
beforeEach →
#deferred = Q.defer()
setTimeout((→
#deferred.resolve(1)
).bind(this), 50)
it 'should throw', (done) →
s = h(#deferred.promise);
s.pull((err, result) →
console.log result
assert false
done()
)
I see your version does indeed work #Louis, but if you involve promises into the mix, mocha can't handle the problem, so it will hang in this example. Also try commenting out the assert false and see it passes.
So Louis I hope I got your attention, could you explain the problem, and try catch looks ugly indeed and I hope you find a reasonable solution to this.
Because that's what you're telling it you want to do, when you add the 'done' callback.
The way to actually do this test is to call return done(err) if the assertion would fail, where err is any string or error object you want reported.
First, when your assertion fails, the program throws an exception and never reaches done(), which is why you're not seeing done get called. This is how assertions are supposed to work, however since you're in an async test, the result is that the callback never fires, which is why you hit the timeout.
Second, as my original answer said err is any error you want to send out from the test. It can be a string error message or a full-on Error object subclass. You create it and then pass it to done() to indicate the test failed.
The better way to structure your code in an asynchronous test is to use your tests as simple booleans, rather than as assertions. If you really want to use assert, then wrap it in a try..catch. Here's a couple examples:
if(err) return done(err); // in this case, err is defined as part of the parent callback signature that you have in your code already.
if(result.length < 1) return done('Result was empty!');
Finally, if you really want to assert, then you can:
try{
assert(!err);
}catch(e){
return done(e);
}
I'm calling return done(err) rather than done(err) because it stops the rest of the code from executing, which is normally what you want.
For anyone with same issue: You should make sure that done() gets called even after an assert fails, like in the following code:
try {
// your asserts go here
done();
} catch (e) {
done(e);
}
When I use Highland.js with a super simple test, Mocha catches the failing assert without any problem:
var _ = require("highland");
var fs = require("fs");
var assert = require("assert");
describe("test", function () {
it("test", function (done) {
var s = _([1, 2, 3, 4]);
s.pull(function (err, result) {
console.log(result);
assert(false);
done();
});
});
});
This suggests that the problem in your example is not Mocha, nor Highland.js. If the articleLinkStream object (or articleSream; it seems to change from snippet to snippet) is custom code then maybe that code is buggy and actually swallows exceptions rather than let them move up the stack.
I'm very new to unit tests, mocha, and should.js, and I'm trying to write a test for an asynchronous method that returns a promise. Here is my test code:
var should = require("should"),
tideRetriever = require("../tide-retriever"),
moment = require("moment"),
timeFormat = "YYYY-MM-DD-HH:mm:ss",
from = moment("2013-03-06T00:00:00", timeFormat),
to = moment("2013-03-12T23:59:00", timeFormat),
expectedCount = 300;
describe("tide retriever", function() {
it("should retrieve and parse tide CSV data", function() {
tideRetriever.get(from, to).then(
function(entries) { // resolve
entries.should.be.instanceof(Array).and.have.lengthOf(expectedCount);
},
function(err) { // reject
should.fail("Promise rejected", err);
}
);
});
});
When I manually test the tideRetriever.get method, it consistently resolves an array of 27 elements (as expected), but the test will not fail regardless of the value of expectedCount. Here is my simple manual test:
tideRetriever.get(from, to).then(
function(entries) {
console.log(entries, entries.length);
},
function(err) {
console.log("Promise rejected", err);
}
);
I can also post the source for the module being tested if it's necessary.
Am I misunderstanding something about Mocha or should.js? Any help would be greatly appreciated.
UPDATE
At some point Mocha started to support returning Promise from test instead of adding done() callbacks. Original answer still works, but test looks much cleaner with this approach:
it("should retrieve and parse tide CSV data", function() {
return tideRetriever.get(from, to).then(
function(entries) {
entries.should.be.instanceof(Array).and.have.lengthOf(expectedCount);
}
);
});
Check out this gist for complete example.
ORIGINAL
CAUTION. Accepted answer works only with normal asynchronous code, not with Promises (which author uses).
Difference is that exceptions thrown from Promise callbacks can't be caught by application (in our case Mocha) and therefore test will fail by timeout and not by an actual assertion. The assertion can be logged or not depending on Promise implementation. See more information about this at when documentation.
To properly handle this with Promises you should pass err object to the done() callback instead of throwing it. You can do it by using Promise.catch() method (not in onRejection() callback of Promise.then(), because it doesn't catch exceptions from onFulfilment() callback of the same method). See example below:
describe("tide retriever", function() {
it("should retrieve and parse tide CSV data", function(done) {
tideRetriever.get(from, to).then(
function(entries) { // resolve
entries.should.be.instanceof(Array).and.have.lengthOf(expectedCount);
done(); // test passes
},
function(err) { // reject
done(err); // Promise rejected
}
).catch(function (err) {
done(err); // should throwed assertion
});
});
});
PS done() callback is used in three places to cover all possible cases. However onRejection() callback can be completely removed if you don't need any special logic inside it. Promise.catch() will handle rejections also in this case.
When testing asynchronous code, you need to tell Mocha when the test is complete (regardless of whether it passed or failed). This is done by specifying an argument to the test function, which Mocha populates with a done function. So your code might look like this:
describe("tide retriever", function() {
it("should retrieve and parse tide CSV data", function(done) {
tideRetriever.get(from, to).then(
function(entries) { // resolve
entries.should.be.instanceof(Array).and.have.lengthOf(expectedCount);
done();
},
function(err) { // reject
should.fail("Promise rejected", err);
done();
}
);
});
});
Note that the way Mocha knows this is an async test and it needs to wait until done() is called is just by specifying that argument.
Also, if your promise has a "completed" handler, which fires both on success and failure, you can alternatively call done() in that, thus saving a call.
More info at:
http://mochajs.github.io/mocha/#asynchronous-code