Testing the routes

Let's start things a little slowly by taking a look at one of the most basic files in our application, the routes.js file. This file simply defines the number of routes that the application should respond to. This will be one of the easiest files to write tests for.

Since the routes.js file is in the server folder within our main application, let's put its corresponding test file in a similar location. Within the tests/server folder, create a file named routes.test.js. Since the routes.test.js file will be testing the functionalities of our routes.js file, we will need it to require the same modules.

Include the following code in test/server/routes.test.js:

const home = require('../../controllers/home'), 
image = require('../../controllers/image'),
routes = require('../../server/routes');

Note that the paths are different since we require modules from within our test/server folder, but we also require app-specific modules. Also, note that in addition to the modules that our original routes.js file requires, we also require the routes module itself. How else will we be able to test the functionalities of the module if it isn't included? Next, let's set up the structure of the test suite and create a few spies. Include this new block of code following the previous code within tests/server/routes.test.js:

describe('Routes',()=>{ 
let app = {
get: sinon.spy(),
post: sinon.spy(),
delete: sinon.spy()
};
beforeEach(()=>{
routes.initialize(app);
});

// to do: write tests...
});

If you recall, the routes module's initialize function accepted a single parameter, an app object. In our tests, we defined app as a simple, anonymous object with three functions-- get, post, and delete; each of these is a spy. We include a beforeEach block to execute the initialize function before every one of our test runs.

Now, let's include some tests. First, we'll test that the GET endpoints are configured correctly. Immediately after the // to do: write tests... comment, place the following block of code:

describe('GETs',()=>{ 
it('should handle /', function(){
expect(app.get).to.be.calledWith('/', home.index);
});
it('should handle /images/:image_id', ()=>{
expect(app.get).to.be.calledWith('/images/:image_id',
image.index);
});
});

Then, test the POST endpoints:

describe('POSTs', ()=>{
it('should handle /images', ()=>{
expect(app.post).to.be.calledWith('/images', image.create);
});
it('should handle /images/:image_id/like', ()=>{
expect(app.post).to.be.calledWith('/images/:image_id/like', image.like);
});
it('should handle /images/:image_id/comment', ()=>{
expect(app.post).to.be.calledWith('/images/:image_id/comment', image.comment);
});
});

Finally, test the DELETE endpoint:

describe('DELETEs', ()=>{
it('should handle /images/:image_id', ()=>{
expect(app.delete).to.be.calledWith('/images/:image_id', image.remove);
});
});

Each of these tests asserts the same thing, that is, that app object's corresponding get, post, or delete function was executed with the correct parameters for each route. We were able to test against the parameters because the app object we used was a spy.

If you run the mocha command to execute the suite of tests, you should see the following output:

    $ npm test
Routes
GETs
should handle /
should handle /images/:image_id
POSTs
should handle /images
should handle /images/:image_id/like
should handle /images/:image_id/comment
DELETEs
should handle /images/:image_id

6 passing (14ms)
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.145.73.207