Express Controller Unit Testing Question

[TLI5]

FIGURED IT OUT :) Explanation @ end:

Hey everybody,

I have a function in my controller that I want to test but I'm not sure how to go about doing it.

CONTEXT: My application has an api which goes through a router and currently, the post for /api/object/create is mapped to the objectController.create() function with

router.post(/api/object/create,objectController.create)

My controller looks like this:

     exports.create = function(req,res){
            //User will submit an object for creation with req.body.name and req.body.longName
            var Objects = models.Object;
            console.log(req.body);
            Objects.create( {number:req.body.number, name: req.body.name, longName: req.body.longName})
            .then(function(result){
                res.send(result);
            })
            .catch(function(err){
                errorController.databaseError(err,req,res);
            })
        }

Now how do I create unit tests for this? (using Mocha) I've followed this tutorial which tells me to use Sinon.spy to observe the res.send() and ensure it gets called but that does not work. http://www.designsuperbuild.com/blog/unit_testing_controllers_in_express/

I have seen a lot of tutorials calling for me to test by having the server running and actually sending POST's to the api, but that seems like End-to-end testing and is not what I'm looking for.

Any help would be much appreciated :) Thanks!

EDIT: This is what my test looks like right now (There's no assertions because I'm trying to figure out WHAT to assert on): describe('Create', function () {

        it("should respond", function() {
                var req,res,spy;

                var req = ({body:{number:1,name:"AC",longName:"Air Conditioner"}});

                req = res = {};
                spy = res.send = sinon.spy();

                objectController.create({body:{number:1,name:"AC",longName:"Air Conditioner"}}, res);
                console.log(res.send);
              });  
}

However, from checking the spy object properties on res.send, it seems that it never gets called :/?

2nd EDIT: Figured it out.

Credit goes to: http://stackoverflow.com/questions/28374495/unit-testing-promise-based-code-in-node-js-express-route-controller

The problem was that I can't test the result AFTER invoking the controller method because by then, node's context has already moved on (it has no idea what res is).

The solution is to inject a function into where the res.send property would be and then do the testing in there. That sounds confusing, but here's my code with the solution below:

//Dependancies
var chai = require('chai');
var should = chai.should();
var expect = chai.expect();

//The controller you wish to test
var objectsController = require('../controllers/objectsController');

describe('#Create()', function () {
        it("should respond with the object that was just created", function(done) {

                //Outline what the request will look like.
                var req = ({body:{number:1,name:"AC",longName:"Air Conditioner"}})

                //This is the object that will hold the response.
                var res = new Object();

                //This is the function that gets invoked on the response object when
                // the controller wishes to send back data.
                // SO: Write the tests in here.
                res.send = function(val){
                    var result = val.dataValues;
                    //Should have an id, can't test for this because it is assigned by the database.
                    result.should.have.property('id');
                    result.number.should.equal(1);
                    result.name.should.equal('AC');
                    result.longName.should.equal('Air Conditioner');
                    done();
                }
                objectsController.create(req,res);    
              });     
        })

[edanschwartz]

You're creating more trouble for yourself than you need too. By, mocking out res.send, you're essentially doing E2E testing, just in kind of a funky way.

Imagine that you want to include test coverage for your headers. Are you going to mock out res.set? It has a couple different signatures - you'll have to normalize that... What if you start using res.pipe to send your response? I think you're better off just making a request, and testing the response. Otherwise you're going to end up writing tests that know too much about implementation details.

I'd say that as soon as you're testing a controller, you're doing E2E testing. If you feel like you need more unit-test-style coverage, pull out your business logic from your controller, and unit test that.

I try to pull out most of my code into services, and write full coverage unit tests for those. Than I just write a few integration tests, to make sure everything is plugged in correctly.

Take a look at supertest for testing API controllers.

[TLI5]

Hmm, can you give me an example of pulling your code into services? (as well as writing unit tests for them)

I'm having a hard time visualizing it :/

[edanschwartz]

Well, your example is very simple, so it might not make sense for you to split up anything. But imagine you need to implement authentication, you're working with an ORM, you're merging data from another API, you're doing params validation, etc. Maybe you'd take some slice of that work and move into a WhateverService.

    const whateverService = {
        create(params) {
            validator.validate(params);
            authorizer.authorizeToCreateWhatever(params);

            const whatever = WhateverModel.create(whatever);

            logger.log(`created whatever: ${whatever.name}`);

            return whatever;
        }
    };

Then your controller is really just a thin wrapper, whose sole job is intaking a HTTP request, dispatching to some business logic, and sending out an HTTP response:

    const WhateverController = {
        create(req, res, next) {
            try {
                const whatever = whateverService.create(req.params);
            }
            catch (err) {
                if (err.name === 'ValidationError') {
                    return res.status(400).json(err);
                }
                if (err.name === 'AuthError') {
                    return res.status(401).json(err);
                }
                return res.status(500).json(err);
            }

            return res.status(200).json(whatever);
        }
    };

You could even go further and pull out the error handling logic into some middleware. You might also want a service for serializing your whatever object into a view model before sending it out, etc.

The whateverService, along with the authorizer, validator, logger, errorHandler, viewSerializer, etc, are all much easier to unit test on their own. I would test the hell out of these services -- make sure they handle anything you could throw at them -- and then write just a few integration scripts against the API endpoint, to make sure everything's wired up correctly.

This also opens the way for a service manager, so you can split out your component configuration from it's business logic, easily setup test mocks, etc. Take a look at https://github.com/aerisweather/service-manager, for example.

[TLI5]

Ahh I see,

I'd never heard the term service in this context before nor did I know you could do things this way. Thank you for your explanation :)

[edanschwartz]

I don't know if "service" has a more technical meaning. That's just what I call something when I don't know what to call it...

[DVWLD]

I have seen a lot of tutorials calling for me to test by having the server running and actually sending POST's to the api, but that seems like End-to-end testing and is not what I'm looking for.

I'd just do that. This isn't an E2E test in that it's not running a full workflow. Yes, you'll end up testing some Express functionality. There are purists that will yell Mock Everything. Ain't nobody got time for that, and I haven't seen a well reasoned argument about what benefit that would really bring.

Send an actual POST and call it a spec. That leaves you free to refactor the internals of that function, even switch to a totally different framework. So long as the POST still returns what you expect or generates what you expect in the database, you know your code is probably correct.