If I have the following module:
module.exports = kontinue => {
Promise.resolve({error:null})
.then(o => {
console.log('promise resolved');
// say something goes wrong here
if(true)
kontinue({error:'promise resolved but something else went wrong'});
else kontinue(o);
})
.catch(error => {
console.log('caught error');
kontinue({error:'promise rejected, or resolved but then continuation threw exception'})
});
};
And the following test:
const assert = require('assert').strict;
const target = require('./the_above_code.js');
it('should not timeout', (done) => {
target((sut) => {
console.log('continuation called');
assert.ok(false); // the test for sut.error === what I expected was failing
done();
});
});
It outputs:
promise resolved
continuation called
caught error
...
Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.
I realise this is because the .catch() is returning a new promise which is not resolving, but that's not what I really want during testing.
How do I test the object a promise resolves to, fail the test if necessary, have Mocha report that failure?
Perhaps there is somewhere else other than in the continuation (which never returns in the code that uses this module) that I can put the tests?
I'm sure monads can reduce the amount of boilerplate code here, but using them surely would violate Kernighan's maxim.
Related
I have the following need to test whether something does not happen.
While testing something like that may be worth a discussion (how long wait is long enough?), I hope there would exist a better way in Jest to integrate with test timeouts. So far, I haven't found one, but let's begin with the test.
test ('User information is not distributed to a project where the user is not a member', async () => {
// Write in 'userInfo' -> should NOT turn up in project 1.
//
await collection("userInfo").doc("xyz").set({ displayName: "blah", photoURL: "https://no-such.png" });
// (firebase-jest-testing 0.0.3-beta.3)
await expect( eventually("projects/1/userInfo/xyz", o => !!o, 800 /*ms*/) ).resolves.toBeUndefined();
// ideally:
//await expect(prom).not.toComplete; // ..but with cancelling such a promise
}, 9999 /*ms*/ );
The eventually returns a Promise and I'd like to check that:
within the test's normal timeout...
such a Promise does not complete (resolve or reject)
Jest provides .resolves and .rejects but nothing that would combine the two.
Can I create the anticipated .not.toComplete using some Jest extension mechanism?
Can I create a "run just before the test would time out" (with ability to make the test pass or fail) trigger?
I think the 2. suggestion might turn handy, and can create a feature request for such, but let's see what comments this gets..
Edit: There's a further complexity in that JS Promises cannot be cancelled from outside (but they can time out, from within).
I eventually solved this with a custom matcher:
/*
* test-fns/matchers/timesOut.js
*
* Usage:
* <<
* expect(prom).timesOut(500);
* <<
*/
import { expect } from '#jest/globals'
expect.extend({
async timesOut(prom, ms) { // (Promise of any, number) => { message: () => string, pass: boolean }
// Wait for either 'prom' to complete, or a timeout.
//
const [resolved,error] = await Promise.race([ prom, timeoutMs(ms) ])
.then(x => [x])
.catch(err => [undefined,err] );
const pass = (resolved === TIMED_OUT);
return pass ? {
message: () => `expected not to time out in ${ms}ms`,
pass: true
} : {
message: () => `expected to time out in ${ms}ms, but ${ error ? `rejected with ${error}`:`resolved with ${resolved}` }`,
pass: false
}
}
})
const timeoutMs = (ms) => new Promise((resolve) => { setTimeout(resolve, ms); })
.then( _ => TIMED_OUT);
const TIMED_OUT = Symbol()
source
The good side is, this can be added to any Jest project.
The down side is, one needs to separately mention the delay (and guarantee Jest's time out does not happen before).
Makes the question's code become:
await expect( eventually("projects/1/userInfo/xyz") ).timesOut(300)
Note for Firebase users:
Jest does not exit to OS level if Firestore JS SDK client listeners are still active. You can prevent it by unsubscribing to them in afterAll - but this means keeping track of which listeners are alive and which not. The firebase-jest-testing library does this for you, under the hood. Also, this will eventually ;) get fixed by Firebase.
I'm trying to assert that a method is called, so I've stubbed it:
import * as dataActions from '../../../src/redux/data.actions';
it.only('sends start request', () => {
cy.visit('/')
const stub = cy.stub(dataActions, 'handleMessage', () => console.trace('HELLO FROM FAKE')).as('messageStub')
expect(stub).not.to.be.called;
cy.contains(/start/i).click() // this will call handleMessage
expect(stub).to.be.called;
});
I have confirmed that the stub is definitely preventing the actual handleMessage from being called. However, the test fails on the final assertion. And it does so immediately, without any of Cypress's famous timeout.
But although it fails, the stub is somehow called four times. I can see "HELLO FROM FAKE" in the console, and the cypress log shows four invocations of the stub:
And the behavior is very strange: If I comment out the final assertion, the method is not stubbed (the actual implementation is called) and the fake is never called.
What is going on here?
UPDATE: A trip to the cypress docs implies that you're supposed to assert on the actual method, not the returned stub. However, the following gets the exact same result:
it.only('sends start request', () => {
cy.visit('/')
cy.stub(dataActions, 'handleMessage', () => console.log('HELLO FROM FAKE')).as('messageStub')
cy.contains(/start/i).click()
expect(dataActions.handleMessage).to.have.been.called;
});
Like it was said in the comments, you must wait for the click. So the correct code should be:
it.only('sends start request', () => {
cy.visit('/')
cy.stub(dataActions, 'handleMessage', () => console.log('HELLO FROM FAKE')).as('messageStub')
cy.contains(/start/i).click().then(() => {
expect(dataActions.handleMessage).to.have.been.called;
});
});
Here's the current test:
describe('/POST Register Page', function() {
it('it should register new user', function(/*done*/) {
chai.request(server)
.post('/auth/register')
.send(new_user_data)
.end(function(res) {
expect(res).to.have.status(2017);
// done();
})
})
})
The last I checked, there's no http code as 2017, however, it still passes:
Registration
Get register page
GET /auth/register 200 6.989 ms - 27
✓ it should get register page
/POST Register Page
✓ it should register new user
2 passing (147ms)
I want to simply post something, then get a response back, and play with the response.
If I include the done(), I get the timeout error:
1) Registration /POST Register Page it should register new user:
Error: Timeout of 3000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.
I can't get anything to work, as for whether wrong or right, the tests pass.
Although this get request is passing as expected:
describe('Get register page', function() {
it('it should get register page', function(done) {
chai.request(server)
.get('/auth/register')
.end(function(err, res) {
expect(err).to.be.null;
expect(res).to.have.status(200);
done();
})
})
})
I'm new at this mocha-cum-chai-chai-http thing, and the experience so far is weird.
Thanks.
Your POST request is probably taking longer than 3 seconds to complete, therefore mocha throws the timeout error.
You can try setting the timeout to a larger value like:
describe('/POST Register Page', function() {
// timeout in milliseconds
this.timeout(15000);
// test case
it('it should register new user', function(done) {
chai.request(server)
.post('/auth/register')
.send(new_user_data)
.end(function(res) {
expect(res).to.have.status(200);
done();
})
})
})
With some trial, you can figure out an optimum value of timeout to set in your tests.
When you don't use the done() callback, mocha simply skips the assertions without waiting for the actual response to arrive. Since the assertions in .end() block never get executed, mocha passes the test as it faces no assertions. I had faced something similar when I first started out with TDD, which I learned about the hard way.
Reference:
Because the end function is passed a callback, assertions are run
asynchronously. Therefore, a mechanism must be used to notify the
testing framework that the callback has completed. Otherwise, the test
will pass before the assertions are checked.
I'm writing unit tests using Mocha and shouldjs, and bluebird.
According to the documentation (http://shouldjs.github.io/#assertion-finally) I should be able to return a Promise, and get it tested.
It is being run, but not tested. An assertion is thrown, but the test seemingly passes
Here is my code. It's pretty well straight out of the shouldjs docs:
'use strict';
require('should');
var Promise = require('bluebird');
describe('demo should error', function () {
it('I should fail - but Im not', function () {
var prm = new Promise(function(resolve, reject) { resolve(10); });
return prm.should.be.finally.equal(9);
});
});
When I run this in mocha, I get the following:
>>> mocha tests/demo.js
(node) child_process: options.customFds option is deprecated. Use options.stdio instead.
․Unhandled rejection AssertionError: expected 10 to be 9
at Assertion.fail (/Users/andrew/projects/DELETE_ME/2016-02-07/node_modules/should/lib/assertion.js:91:17)
at Assertion.Object.defineProperty.value (/Users/andrew/projects/DELETE_ME/2016-02-07/node_modules/should/lib/assertion.js:163:19)
...
1 passing (14ms)
So an exception is thrown, but the test seemingly passes.
I also get a false positive when I use native Promise, not bluebird, but the stack trace isn't shown.
Any help gratefully received...
I was using an outdated Mocha...
npm i -g mocha
Did the trick
I came across an issue with running a spec that should be executed after a promise has been resolved. See the commented simplified example below.
I tried using IIFE or calling done() function in the spec but none of these seemed to work.
// getIds() is a simple promise which returns an array of ids
getIds().then(function (ids) {
console.log('IDS: ' + ids); // all good so far
// This test is never run
it('dummy test', function () {
console.log('TEST HAS BEEN RUN');
});
});
You can use browser.wait() to wait until your promise is complete. Or you can put your test inside the then block:
it('should test', function() {
getIds().then(function (ids) {
// some action.
expect()...
});
});
Also, you can put the promise in a beforeEach or a beforeAll (jasmine 2). Assign the ids to a variable declared inside a describe. The value should be available for your test to use.