How to mock req.session on Mocha/Chai API Unit Test - node.js

Using Mocha/Chai for REST API unit testing, I need to be able to mock req.session.someKey for a few of the end points. How can I go about mocking req.session?
I'm working on writing REST API unit tests for a NodeJS Express app that utilizes express-session. Some of these endpoints require the use of data stored in req.session.someKey, the endpoint is setup to return a 400 if req.session.someKey is undefined so I need to be able to mock it in order for the test to complete successfully.
Example code:
router.get('/api/fileSystems', utilities.apiAuth, (req, res) => {
let customer = req.session.customer;
let route = (customer === 'NONE') ? undefined : customer;
if(route == undefined){
res.status(400).send('Can't have customer of undefined');
} else {
let requestOptions = setRequestOptions(route);
queryFileSystemInfo(requestOptions, (info) => {
res.status(200).send(info);
});
}
});
What I've tried:
describe('/GET /api/fileSystems', () => {
it('It should return information about the filesystem for a customer'), (done) => {
chai.request(server)
.get('api/fileSystems')
.set('customer', '146')
.end((err, res) => {
res.should.have.status(200);
done();
});
});
});
I attempted to use the .set() in order to set req.session but I believe that .set just sets the headers so I don't believe that I can update it that way unless I'm missing something.

In your express setup you usually plug in the session middleware like this
app.use(session(config))
instead you can put the session middleware in a handy accessible location, and make a wrapper for it, like this:
app.set('sessionMiddleware') = session(config)
app.use((...args) => app.get('sessionMiddleware')(...args)
Tests will need access to the express instance, you can do this by refactoring /app.js to export a function.
function app () {
const app = express()
// ... set up express
return app
}
// run app if module called from cli like `node app.js`
if (require.main === module) instance = app()
module.exports = app
Then in your test, you can overwrite app.sessionMiddleware
describe('/GET /api/fileSystems', () => {
it('It should return information about the filesystem for a customer'), (done) => {
app.set('sessionMiddleware') = (req, res, next) => {
req.session = mockSession // whatever you want here
next()
}
chai.request(server)
.get('api/fileSystems')
.set('customer', '146')
.end((err, res) => {
res.should.have.status(200);
done();
});
// then you can easily run assertions against your mock
chai.assert.equal(mockSession.value, value)
});
});
The other options I've seen on the net involve setting a cookie to match a session which is stored in the db, the problem with that approach is that you end up running into problems when the session in the db expires, so tests fail over time as fixtures become stale. With the approach outlined above you can work around that by setting expiries in the test.

mock-session is pretty use full to mock your session object
let mockSession = require('mock-session');
describe('/GET /api/fileSystems', () => {
it('It should return information about the filesystem for a customer'), (done) => {
let cookie = mockSession('my-session', 'my-secret', {"count":1}); // my-secret is you session secret key.
chai.request(server)
.get('api/fileSystems')
.set('cookie',[cookie])
.end((err, res) => {
res.should.have.status(200);
done();
});
});
});

For this project, I ended up having to set req.session.customer in our server.js file that has an app.use() call that uses a middleware function to set the current session. I was unable to actually find a package that directly mutates the req.session object at test time.

Related

jest.setTimeout.Error: Mocking Express middleware with Jest and Supertest

I would like to mock the auth middleware function to always just call next(). To try and acheive this, I added the following to the beginning of my test file before the auth middleware function is added to the app in app.js.
jest.mock('../../middleware/auth.js', () =>
// ensure func is mocked before being attached to the app instance
jest.fn((req, res, next) => next()) // seems to only work for first request that hits this middleware
); // Mock authentication
I then added some debugs in the auth middleware but did not hit them for any of the tests.
Currently I am using the following, when the beforeEach() function is not commented out the tests all pass:
role.test.js
jest.mock('../../middleware/auth.js', () =>
// ensure func is mocked before being attached to the app instance
jest.fn((req, res, next) => next()) // seems to only work for first request that hits this middleware
); // Mock authentication
const request = require('supertest');
const app = require('../../app.js');
const Role = require('../../../db/models/index.js').Role;
// const auth = require('../../middleware/auth.js');
/**
* Test role API routes
*/
describe('role-router', () => {
let res;
const token = 'valid-token';
const baseUrl = '/private/api/roles';
// Without the `beforeEach()` only the first request sent using supertest will use the mocked functionality
// With the `beforeEach()` everything functions as expected, but why?
// beforeEach(() => {
// auth.mockImplementation((req, res, next) => next());
// });
describe(`Create new role | post ${baseUrl}`, () => {
describe('When successful', () => {
beforeAll(async () => {
// this will use the proper mocked functionality
res = await request(app)
.post(baseUrl)
.set('Authorization', token)
.send({
roleName: 'Secret Agent',
roleDesc: "World's best secret agent",
...
});
});
// passes
it('Should return 201', () => {
expect(res.status).toBe(201);
});
}); // When successful
}); // Create new role
describe(`Delete role by id | delete ${baseUrl}/:id`, () => {
describe('When successful', () => {
beforeAll(async () => {
const role = await Role.create({
roleName: 'Secret Agent',
roleDesc: "World's best secret agent",
...
});
// fails does not get response, res remains the same as res from previous test
res = await request(app)
.delete(`${baseUrl}/${role.id}`)
.set('Authorization', token)
.send();
});
// fails with 201
it('Should return 204', () => {
expect(res.status).toBe(204);
});
}); // When successful
}); // Delete role
});
Error received:
● role-router › Delete role by id | delete /private/api/roles/:id › When successful › Should return 204
Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Error: Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.
at mapper (node_modules/jest-jasmine2/build/queueRunner.js:29:45)
app.js
// Dependencies
const express = require('express');
const auth = require('./middleware/auth.js');
...
/**
* Express application
*/
const app = express();
// Middleware
app.use(express.json());
...
// Private routes are secured with jwt authentication middleware
app.all('/private/*', (req, res, next) => auth(req, res, next));
// Public routes
...
// Private routes
app.use('/private/api/roles/', require('./components/role/role-router.js'));
...
module.exports = app;
Any ideas why this is not working without using the beforeEach() function to mock the middleware functionality before every test? Perhaps I am missing something more serious?
The reason for such behaviour is that there is spy.mockReset(), jest.resetAllMocks() or enabled resetMocks configuration option. Use restoreMocks option instead for a reasonable default configuration.
The difference between jest.fn(() => ...) and jest.fn().mockImplementation(() => ...) is how they respond to jest.restoreAllMocks(). restoreAllMocks restores original implementation which is a no-op in case of jest.fn(), while () => ... is considered original implementation in case of jest.fn(...). So normally jest.fn(() => ...) implementation isn't expected to be reset.
The difference between jest.resetAllMocks and jest.restoreAllMocks is that the former can make jest.fn(...) a noop but doesn't restore spies to original implementations. This specifically affects spies that are provided in mocked modules once per test suite with jest.mock, yet still doesn't restore global spies. Since this behaviour is rarely desirable, jest.restoreAllMocks() or restoreMocks configuration option are generally preferable. In case there's ever a need for jest.fn(...) implementation to be reset, mockReset or mockImplementation can be done specifically for this spy.

reset a database before each test

I'm using node and supertest for a simple app. I got SQlite3 for the local test database. I did a simple test to get a super inserted into the database. I wanted to reset the database each time a test is run. I'm looking in the docs right now and can't seem to locate it. I figured I would ask here because it seems someone would most likely know the info.
const request = require('supertest');
const server = require('../server');
describe('Authentication', function() {
//database reset here
it('should create a new user /users/registration', function(done) {
request(server)
.post('/users/register')
.send({
username: 'user-name',
email: 'luser-name#gmail.com',
password: '12345'
})
.set('Accept', 'application/json')
.expect(201, done);
});
});
If you want to run any piece of code before each test, you can use beforeEach function in jest
describe('my test', () => {
beforeEach(() => {
// code to run before each test
});
test('test 1', () => {
// code
});
test('test 2', () => {
// code
});
});
So best way to do this is have some logic in your routing functions of your Api
Receive an API request
Check if ['X-MOCK-HEADER'] exists
If it does then route to the mock version of the endpoint
So your mock for create user would always return 201 OK - your mock endpoint would do something like this:
const routes = {
CREATE_USER_OK:() => { return {....} } // make sure these return proper http responses
CREATE_USER_BAD_REQUEST: () { return {...} }
}
return routes[HEADER_VALUE]()
The reason being you're testing the route not the database class in this instance, so you just want to return static data, if you wanna test something else then just change the X-MOCK-HEADER value to whatever you want and add the mock route to return the right http response/code - I'd need to know what the API code looked like to help you on the backend implementation.
If possible stay away from messing with staging databases for testing because down the road you will suffer a LOT of pain as it gradually gets filled with garbage.
Also if you're working with a front end app you can quickly prototype with static data - this is especially useful if you've got a front end team waiting for an API endpoint to say create a login screen.
There's no defined way to reset a sqlite db, just delete the db and recreate.
Sqlite: How do I reset all database tables?
I did this in the file and it works fine
const request = require('supertest');
const server = require('../server');
const knex = require('knex');
const dbConfig = require('../knexfile.js')['test'];
const db = knex(dbConfig);
describe('Authentication', () => {
beforeEach(async () => {
await db('users').truncate();
});
it('should create a new user /users/registration', function(done) {
request(server)
.post('/users/register')
.send({
username: 'user-name',
email: 'luser-name#gmail.com',
password: '12345'
})
.set('Accept', 'application/json')
.expect(201, done);
});
});

Test redirection using jest in express

i am using Jest to test my code.
What i want achieve is to test redirection from http to https. (if it exists if process.env.IS_PRODUCTION).
I don't know how to test it, how to mockup this and so on...
I've tried standard get reqest but don't know how to mockup environment varible or test it in different way
it('should redirect from http to https, (done) => {
request(server)
.get('/')
.expect(301)
.end((err, res) => {
if (err) return done(err);
expect(res.text).toBe('...')
return done();
});
}, 5000);
I expect to be able to test this redirection :)
You could use the node-mocks-http libary which allows you to simulate a request and response object.
Example:
const request = httpMocks.createRequest({
method: 'POST',
url: '/',
});
const response = httpMocks.createResponse();
middlewareThatHandlesRedirect(request, response);
I never worked with jest but I believe that you can check the response.location parameter once the middleware has been called
Preface: I'm not familiar with jest or express or node. But I have found it to be much easier to test explicit configuration (instantiating objects with explicit values) vs implicit configuration (environmental variables and implementation switches on them):
I'm not sure what request or server are but explicit approach might look like:
it('should redirect from http to https, (done) => {
const server = new Server({
redirect_http_to_https: true,
});
request(server)
.get('/')
.expect(301)
.end((err, res) => {
if (err) return done(err);
expect(res.text).toBe('...')
return done();
});
}, 5000);
This allows the test to explicitly configure server to the state it needs instead of mucking with the environment.
This approach also helps to keep process configuration at the top level of your application:
const server = new Server({
redirect_http_to_https: process.env.IS_PRODUCTION,
});

Handle middleware using chai-http Node Js Express

I am facing issue I am testing an api using chai-http but it struck in middlewear means it does not call next() function. Not sure how to handle this, little guide may be helps me alot. Here is my code may be it helps you understand better.
Middleware
function middleware(req, res, next) => {
// doing some stuff
console.log("step 1") // prints
next()
}
API
router.get('/orders', middleware, (req, res) => {
// some stuff
console.log("step 2") // not prints
res.send(result)
})
Test Case
let order = new Order(mockOrder);
order.save((err, order) => {
chai.request(server)
.get('/orders')
.end((err, res) => {
// some stuff
})
})
This update might be useful for you.It is from github.
Another large breaking change is that the chai.request(server) object will automatically close the server connection after the first request. This means if you have code like this:
you'll need to change it to:
const request = chai.request(app).keepOpen()

send authenticated request via supertest with mocha on a passport managed API

It's been 24 hours since I first had this issue. I know there plenty of similar ones, specially on SO but I can't figure out how to solve it.
I have specific requirement :
I have some routes to test without authentication.
I have some routes to test with specific users.
I use a passport local strategy.
So I decided to test my API like :
var request = require('supertest');
...
describe('Routes', function () {
var anAgent;
var anotherAgent;
before(function (done) {
anAgent = request.agent(app);
anotherAgent = request.agent(app);
async.parallel([
function (callback) {
anAgent
.post('/api/users/login')
.send({user:user, password:password})
.expect(200)
.end(callback);
},
function (callback) {
userAgent
.post('/api/users/login')
.send({user:anotherUser, password:anotherPassword})
.expect(200)
.end(callback);
}
], done);
});
describe('/superroute', function () {
it('should return the user', function (done) {
anAgent
.post('/api/superroute')
.send(params)
.expect(200)
.end(function (err, res) {
should.not.exist(err);
res.body.err.should.equal('Super route');
done();
});
});
...
});
...
});
The route /superroute is describe like
express.Router().post('/superroute', auth.ensureAuthenticated, superCtrl.superroute);
Where ensureAuthenticated middleware call the req.isAuthenticated() of passport.
This API works fine when I use it from a simple angular front but when I run the test with mocha, the passport.deserializeUser method is not called and isAuthenticated return false. With the fact that the user is correctly logged and retrieved from the /login call, it's all I know.
So the call returns 401 instead of 200.
What can I've possibly missed ?

Resources