# Writing tests

The best way to test an application is by writing tests that make sure it behaves to clients as we would expect. Feathers makes testing your application a lot easier because the services we create can be tested directly instead of having to fake HTTP requests and responses. In this chapter we will implement unit tests for our users and messages services.

You can run code linting and Mocha tests with:

npm test

This should already pass but it won't be testing any of the functionality we added in the guide so far.

# Test database setup

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

{
  "nedb": "../test/data"
}

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

Note: When using Git for version control, the data/ and test/data folders should be added to .gitignore.

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

npm install shx --save-dev

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

    On Windows the mocha command should look like this:

    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 messages and users services (with all hooks wired up), we could 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 and use the service methods directly. We "fake" authentication by setting params.user manually.

    By default, the generator creates a service test file that only tests that the service exists.

      We can then add similar tests that use the service. The first test below verifies that users can be created, the profile image gets set and the password gets encrypted. The second verifies that the password does not get sent to external requests:

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

          Run npm test one more time, to verify that all tests are passing.

          # 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 (opens new window) we can add it easily:

          npm install nyc --save-dev
          

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

            On Windows, the coverage command looks like this:

            npm run clean & SET NODE_ENV=test& nyc mocha
            

            Now run:

            npm test
            

            This will print out some additional coverage information.

            Note: When using Git for version control, the .nyc_output/ folder should be added to .gitignore.

            # 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 more details about using Feathers, or start building your own first Feathers application!

            Anything unclear or missing? Get help (opens new window) or Edit this page (opens new window)

            Last Updated: 11/17/2020, 3:17:03 PM