Writing tests

Every time we generate a hook or service, the generator will also set up a basic Mocha test that we can use to implement unit tests for it. In this chapter, we will implement unit tests for our hooks and integration tests for the users and messages services.

We can run the code Linter and Mocha tests with

  1. npm test

This will fail initially, since we implemented functionality in our hooks that is not covered by the standard tests. So let’s get those to pass first.

Unit testing hooks

The best way to test individual hooks is to set up a dummy Feathers application with some services that return the data we expect and can test against, then register the hooks and make actual service calls to verify that they return what we’d expect.

The first hook we created was for processing new messages. For this hook, we can create a messages dummy custom service that just returns the same data from the create service method. To pretend we are an authenticated user, we have to pass params.user. For this test, this can be a simple JavaScript object with an _id.

Update test/hooks/process-messages.test.js to the following:

  1. const assert = require('assert');
  2. const feathers = require('@feathersjs/feathers');
  3. const processMessage = require('../../src/hooks/process-message');
  5. describe('\'process-message\' hook', () => {
  6.   let app;
  8.   beforeEach(() => {
  9.     // Create a new plain Feathers application
  10.     app = feathers();
  12.     // Register a dummy custom service that just return the
  13.     // message data back
  14.     app.use('/messages', {
  15.       async create(data) {
  16.         return data;
  17.       }
  18.     });
  20.     // Register the `processMessage` hook on that service
  21.     app.service('messages').hooks({
  22.       before: {
  23.         create: processMessage()
  24.       }
  25.     });
  26.   });
  28.   it('processes the message as expected', async () => {
  29.     // A user stub with just an `_id`
  30.     const user = { _id: 'test' };
  31.     // The service method call `params`
  32.     const params = { user };
  34.     // Create a new message with params that contains our user
  35.     const message = await app.service('messages').create({
  36.       text: 'Hi there',
  37.       additional: 'should be removed'
  38.     }, params);
  40.     assert.equal(message.text, 'Hi there');
  41.     // `userId` was set
  42.     assert.equal(message.userId, 'test');
  43.     // `additional` property has been removed
  44.     assert.ok(!message.additional);
  45.   });
  46. });

We can take a similar approach to test the gravatar hook in test/hooks/gravatar.test.js:

  1. const assert = require('assert');
  2. const feathers = require('@feathersjs/feathers');
  3. const gravatar = require('../../src/hooks/gravatar');
  5. describe('\'gravatar\' hook', () => {
  6.   let app;
  8.   beforeEach(() => {
  9.     app = feathers();
  11.     // A dummy users service for testing
  12.     app.use('/users', {
  13.       async create(data) {
  14.         return data;
  15.       }
  16.     });
  18.     // Add the hook to the dummy service
  19.     app.service('users').hooks({
  20.       before: {
  21.         create: gravatar()
  22.       }
  23.     });
  24.   });
  26.   it('creates a gravatar link from the users email', async () => {
  27.     const user = await app.service('users').create({
  28.       email: 'test@example.com'
  29.     });
  31.     assert.deepEqual(user, {
  32.       email: 'test@example.com',
  33.       avatar: 'https://s.gravatar.com/avatar/55502f40dc8b7c769880b10874abc9d0?s=60'
  34.     });
  35.   });
  36. });

In the tests above, we created a dummy service. But sometimes, we need the full Feathers service functionality. feathers-memory is a useful database adapter that supports the Feathers query syntax (and pagination) but does not require a database server. We can install it as a development dependency:

  1. npm install feathers-memory --save-dev

Let’s use it to test the populateUser hook, by updating test/hooks/populate-user.test.js to the following:

  1. const assert = require('assert');
  2. const feathers = require('@feathersjs/feathers');
  3. const memory = require('feathers-memory');
  4. const populateUser = require('../../src/hooks/populate-user');
  6. describe('\'populate-user\' hook', () => {
  7.   let app, user;
  9.   beforeEach(async () => {
  10.     // Database adapter pagination options
  11.     const options = {
  12.       paginate: {
  13.         default: 10,
  14.         max: 25
  15.       }
  16.     };
  18.     app = feathers();
  20.     // Register `users` and `messages` service in-memory
  21.     app.use('/users', memory(options));
  22.     app.use('/messages', memory(options));
  24.     // Add the hook to the dummy service
  25.     app.service('messages').hooks({
  26.       after: populateUser()
  27.     });
  29.     // Create a new user we can use to test with
  30.     user = await app.service('users').create({
  31.       email: 'test@user.com'
  32.     });
  33.   });
  35.   it('populates a new message with the user', async () => {
  36.     const message = await app.service('messages').create({
  37.       text: 'A test message',
  38.       // Set `userId` manually (usually done by `process-message` hook)
  39.       userId: user.id
  40.     });
  42.     // Make sure that user got added to the returned message
  43.     assert.deepEqual(message.user, user);
  44.   });
  45. });

If we now run:

  1. npm test

All our tests should pass. Yay!

Note: There are some error stacks printed when running the tests. This is normal, they are log entries when running the tests for 404 (Not Found) errors.

Test database setup

When testing database functionality, we want to make sure that the tests use a different database. We can achieve this by creating a new environment configuration in config/test.json with the following content:

  1. {
  2.   "nedb": "../test/data"
  3. }

This will set up the NeDB database to use test/data as the base directory instead of data/ when NODE_ENV is set to test. The same thing can be done with connection strings for other databases.

We also want to make sure that before every test run, the database is cleaned up. To make that possible across platforms, first run:

  1. npm install shx --save-dev

Now we can update the script section of package.json to the following:

  1.   "scripts": {
  2.     "test": "npm run eslint && npm run mocha",
  3.     "eslint": "eslint src/. test/. --config .eslintrc.json",
  4.     "start": "node src/",
  5.     "clean": "shx rm -rf test/data/",
  6.     "mocha": "npm run clean && NODE_ENV=test mocha test/ --recursive --exit"
  7.   }

On Windows the mocha should look like:

  1. npm run clean & SET NODE_ENV=test& mocha test/ --recursive --exit

This will make sure that the test/data folder is removed before every test run and NODE_ENV is set properly.

Testing services

To test the actual messages and users services (with all hooks wired up), we can use any REST API testing tool to make requests and verify that they return correct responses.

But there is a much faster, easier and complete approach. Since everything on top of our own hooks and services is already provided (and tested) by Feathers, we can require the application object using the service methods directly, and “fake” authentication by setting params.user as demonstrated in the hook tests above.

By default, the generator creates a service test file, e.g. test/services/users.test.js, that only tests that the service exists, like this:

  1. const assert = require('assert');
  2. const app = require('../../src/app');
  4. describe('\'users\' service', () => {
  5.   it('registered the service', () => {
  6.     const service = app.service('users');
  8.     assert.ok(service, 'Registered the service');
  9.   });
  10. });

We can then add similar tests that use the service. Following is an updated test/services/users.test.js that adds two tests. The first verifies that users can be created, the gravatar gets set and the password gets encrypted. The second verifies that the password does not get sent to external requests:

  1. const assert = require('assert');
  2. const app = require('../../src/app');
  4. describe('\'users\' service', () => {
  5.   it('registered the service', () => {
  6.     const service = app.service('users');
  8.     assert.ok(service, 'Registered the service');
  9.   });
  11.   it('creates a user, encrypts password and adds gravatar', async () => {
  12.     const user = await app.service('users').create({
  13.       email: 'test@example.com',
  14.       password: 'secret'
  15.     });
  17.     // Verify Gravatar has been set as we'd expect
  18.     assert.equal(user.avatar, 'https://s.gravatar.com/avatar/55502f40dc8b7c769880b10874abc9d0?s=60');
  19.     // Makes sure the password got encrypted
  20.     assert.ok(user.password !== 'secret');
  21.   });
  23.   it('removes password for external requests', async () => {
  24.     // Setting `provider` indicates an external request
  25.     const params = { provider: 'rest' };
  27.     const user = await app.service('users').create({
  28.       email: 'test2@example.com',
  29.       password: 'secret'
  30.     }, params);
  32.     // Make sure password has been removed
  33.     assert.ok(!user.password);
  34.   });
  35. });

We take a similar approach for test/services/messages.test.js. We create a test-specific user from the users service. We then pass it as params.user when creating a new message, and validates that message’s content:

  1. const assert = require('assert');
  2. const app = require('../../src/app');
  4. describe('\'messages\' service', () => {
  5.   it('registered the service', () => {
  6.     const service = app.service('messages');
  8.     assert.ok(service, 'Registered the service');
  9.   });
  11.   it('creates and processes message, adds user information', async () => {
  12.     // Create a new user we can use for testing
  13.     const user = await app.service('users').create({
  14.       email: 'messagetest@example.com',
  15.       password: 'supersecret'
  16.     });
  18.     // The messages service call params (with the user we just created)
  19.     const params = { user };
  20.     const message = await app.service('messages').create({
  21.       text: 'a test',
  22.       additional: 'should be removed'
  23.     }, params);
  25.     assert.equal(message.text, 'a test');
  26.     // `userId` should be set to passed users it
  27.     assert.equal(message.userId, user._id);
  28.     // Additional property has been removed
  29.     assert.ok(!message.additional);
  30.     // `user` has been populated
  31.     assert.deepEqual(message.user, user);
  32.   });
  33. });

Run npm test one more time, to verify that the tests for all our hooks, and the new service tests pass.

Code coverage

Code coverage is a great way to get some insights into how much of our code is actually executed during the tests. Using Istanbul we can add it easily:

  1. npm install istanbul@1.1.0-alpha.1 --save-dev

Now we have to update the script section of our package.json to:

  1.   "scripts": {
  2.     "test": "npm run eslint && npm run coverage",
  3.     "coverage": "npm run clean && NODE_ENV=test istanbul cover node_modules/mocha/bin/_mocha -- test/ --recursive --exit",
  4.     "eslint": "eslint src/. test/. --config .eslintrc.json --fix",
  5.     "start": "node src/",
  6.     "clean": "shx rm -rf test/data/",
  7.     "mocha": "npm run clean && NODE_ENV=test mocha test/ --recursive --exit"
  8.   },

On Windows, the coverage command looks like this:

  1. npm run clean & SET NODE_ENV=test& istanbul cover node_modules/mocha/bin/_mocha -- test/ --recursive --exit

To get more coverage information, add a .istanbul.yml in the main folder:

  1. verbose: false
  2. instrumentation:
  3.   root: ./src/
  4. reporting:
  5.   print: summary
  6.   reports:
  7.     - html
  8.     - text
  9.     - lcov
  10.   watermarks:
  11.     statements: [70, 90]
  12.     lines: [70, 90]
  13.     functions: [70, 90]
  14.     branches: [70, 90]

Now run:

  1. npm test

This will print out some additional coverage information and put a complete HTML report into the coverage folder.

Changing the default test directory

To change the default test directory, specify the directory you want in your project’s package.json file:

  1. {
  2.   "directories": {
  3.     "test": "server/test/"
  4.   }
  5. }

Also, don’t forget to update your mocha script in your package.json file:

  1.   "scripts": {
  2.     "mocha": "mocha server/test/ --recursive --exit"  
  3.   }

What’s next?

That’s it - our chat guide is completed! We now have a fully-tested REST and real-time API, with a plain JavaScript frontend including login and signup. Follow up in the Feathers API documentation for complete details about using Feathers, or start building your own first Feathers application!