When unit-testing ExpressJS route controllers and middleware you need to make dummy req and res objects to pass in as parameters. The req param needs a bunch of properties, most-typically body , query , and params objects, as well as the get function for accessing headers. The res param typically needs end , json , send , and status functions, as well as whatever else your function uses. In the case of the status function, your fake res object needs to ensure its status function is chainable.

To make this simple I have published mock-req-res , which exposes mockRequest and mockResponse functions your unit-tests can use to generate consistent and useful mock req and res objects.

The mock request

const req = mockRequest(options)

The options can be whatever you wish. The defaults are:

body: {},

cookies: {},

query: {},

params: {}

The get function is supplied as a sinon stub .

The mock response

const res = mockResponse(options)

The default options are:

clearCookie: spy(),

cookie: spy(),

download: spy(),

end: spy(),

format: spy(),

json: spy(),

jsonp: spy(),

redirect: spy(),

render: spy(),

send: spy(),

sendFile: spy(),

sendStatus: spy(),

set: spy(),

type: spy()

In this case most of the default functions are set to be sinon spies , so your tests can simply expect(res.end).to.have.been.calledOnce . Just like the request object, the get function is stubbed, allowing your test to control what get returns.

Both the status and vary functions are stubbed and set to return the response object, allowing chaining.

Options

Both the mockRequest and mockResponse functions return objects that include the most commonly used defaults. They can be passed an options object whose root-level values are simply merged in with those defaults, with any duplicates overwriting the defaults. So if there are specific properties of a request object you need then just pass it in as an option .

Example usage

Assume you have an ExpressJS route controller function as follows:

const save = require('../../utils/saveThing') // assume this exists. const createThing = (req, res) => {

const { name, description } = req.body

if (!name || !description) throw new Error('Invalid Properties')

const saved = save({ name, description })

res.json(saved)

}

To unit-test this you could use Mocha , Chai , Sinon , and Proxyquire as follows:

const { expect } = require('chai')

const { stub, match } = require('sinon')

const { mockRequest, mockResponse } = require('mock-req-res')

const proxyquire = require('proxyquire') describe('src/api/things/createThing', () => {

const mockSave = stub() const createThing = proxyquire('../../src/api/things/createThing', {

'../../utils/saveThing': mockSave

}) const res = mockResponse() const resetStubs = () => {

mockSave.resetHistory()

res.json.resetHistory()

} context('happy path', () => {

const name = 'some name'

const description = 'some description' const req = mockRequest({ body: { name, description }})

const expected = { name, description, id: 1 }



before(() => {

save.returns(expected)

createThing(req, res)

}) after(resetStubs) it('called save with the right data', () => {

expect(save).to.have.been.calledWith(match({

name,

description

}))

}) it('called res.json with the right data', () => {

expect(res.json).to.have.been.calledWith(match(expected))

})

}) // and also test the various unhappy path scenarios.

})

Summary

Using a standard library for mocking request and response objects saves you a lot of tiresome repetition when the number of functions you have to test grows, or you find yourself writing a large collection of microservices.

The mock-req-res library is as minimal as possible, and only requires sinon as a peer dependency.

Links