danawoodman/sinon-express-mock

Simple request and response mock objects to pass into Express routes when testing using Sinon.

sinon-express-mock

Simple request and response mock objects to pass into Express routes when testing using Sinon.

The mock objects attach Sinon spys to request methods. See src/index.js for a full list of stubbed out methods.

Install

npm install --save-dev sinon-express-mock sinon

Depends on:

• Node v4+ (or Object.assign support needed)
• Sinon

Usage

Contents of src/foo.js:

export default (req, res) => {
  res.json({ foo: req.body.foo })
}

Contents of test/foo-test.js:

import route from '../src/foo'
import chai, { expect } from 'chai'
import sinonChai from 'sinon-chai'
import { mockReq, mockRes } from 'sinon-express-mock'

chai.use(sinonChai);

describe('my route', () => {
  it('should foo the bar', () => {
    const request = {
      body: {
        foo: 'bar',
      },
    }
    const req = mockReq(request)
    const res = mockRes()

    route(req, res)

    expect(res.json).to.be.calledWith({ foo: request.body.foo })
  })
})

Changelog

v2.0.3

• res.write() is now stubbed.

v2.0.0

• Make sinon a peerDependency.

v1.3.1

• Bundle fix from #3

pre v1.3.1

• Changelog didn't exist! 😱

Credits

Dana Woodman and contributors

License

MIT

sinon-express-mock's Issues

How do you do POST request mocks?

I have tried moqReq({ method: 'POST'}), but no luck. I don't see anything for it in the code either.

Unlisted dependencies?

The example code uses

expect(res.json).to.be.calledWith({ foo: request.body.foo.bar })

but only imports

import route from "../src/foo" import { mockReq, mockRes } from "sinon-express-mock"

Where is "expect" coming from? chai-http has an expect().to.be.calledWith method, but just using it in conjunction with the example code still throws the same error.

Mocked next?

What's the recommended way to handle routes that use next for error handling?

Typo: res.attachement

according to https://expressjs.com/en/api.html#res.attachment, it should be attachment

Example test missing sinon-chai library

expect(res.json).to.be.calledWith({ foo: request.body.foo }) is syntax from the sinon-chai library, and only worked with the following:

const chai = require('chai');
const sinonChai = require('sinon-chai');
const expect = chai.expect;
chai.use(sinonChai);

Verifying the response state (without knowing how it is set by the implementation)?

As an example of the kind of I'm wanting to do: say I check the return code of a route, something like this:

    // Handler definition
   const route = (req, res) => {
        res.send({name: 'foo'}); // implies status 200
    };

   // Test
   describe('#/api/user', function() {
        it('should get the username', () => {
            const req = mockReq();
            const res = mockRes();
            route(req, res);

            expect(res.statusCode).to.equal(200); // check the return code is 200 OK
            // ...
        });
    });

However, the stub request object has no internal state like a real request would. I don't want to build in the requirement that the res#statusCode method is actually called explicitly (not least because there's a #status alias, and possibly other things going on internally). So what I imagine is an extremely common case is difficult to verify.

This generalises to all the other methods of Request and Response objects which return internal state. It looks like the stub objects need to wrap real ones for this to be achievable correctly.

But possibly this has been anticipated and there's an easy workaround that makes res.statusCode return 200 by default, or something else if a status code was set - just not documented?

peerDependency warning for [email protected]

Hi there!

Pleased to be using your library in our project, however I keep receiving peerDep warnings from npm

npm WARN [email protected] requires a peer of [email protected] but none is installed. You must install peer dependencies yourself.

We're using [email protected] and this library still works a treat. Would it be alright if the peerDep was changed to "^4.1.3" to catch the other minor versions in sinon v4? Submitting a PR for this one now

Persist mutations to locals

Locals can not currently be mutated after their assignment. This causes issues when testing the following:

const middleware = (req, res, next) => {
  res.locals.myVar = "new";
  next();
};

const req = mockReq();
const res = mockRes({ locals: { myVar: "old" } });

middleware(req, res, spy());

res.locals.myVar // "old"

This is useful to test as some middleware can be reliant on previous middleware setting locals (such as decoding tokens).

@danawoodman I noticed from #12 that you mentioned you're not actively maintaining this repo anymore, in which case I'll get around to this when I get a chance. Otherwise if anyone else notices this I'm happy for them to pick this up.

Unmet peer dependency [email protected] (revisited)

I don't think I can reopen issue #10 now you've closed it, and perhaps you don't get notifications when I add comments to it.

So, to recapitulate what I said there: I think this issue is still unresolved: package.json's peerDependencies is still configured as ^4.1.3.

chainable functions

suppose i were testing this route handler

// myroute.js
module.exports = function(req, res) {
    return res.status(200).end()
}

with this test case

it('should call end', function() {
    var myroute = require('./myroute')
    var res = mockRes()
    myroute(null, res)
    expect(res.end).to.be.called
})
// TypeError: Cannot read property 'end' of undefined

the type error being thrown is because the stubbed res.status function is a sinon spy and does not return res. could it be possible to alter this library to support chaining function calls in a backwards compatible manner?

i'd be happy to have a go at adding this, just wanted to get your thoughts on the matter 🙏

Unmet peer dependecy: [email protected]

I gather sinon-express-mock currently lists sinon ^4.1.3 as a peer dependency.

Sinon's current release is now 5.0.7.

Is there a plan to update to, or otherwise allow current Sinon releases? Or do I need to downgrade Sinon to use sinon-express-mock?

Thanks!

mockNext?

It would be nice to have the mock for the next() function.
I am testing some middleware in typescript and it would be useful.

I can make a PR if you'd like.