CI/CD With Travis CI and Coveralls in Node/Express API
Tags: travisci, coveralls, testing, node
Published: 2019-09-04 20:01:13

 _This article was originally published on my [blog](https://www.oriechinedu.com/posts/ci-cd-with-travis-and-coveralls-in-node)_

In the previous [article](https://www.oriechinedu.com/posts/testing-nodejs-express-api-with-jest-and-supertest/), we wrote end-to-end tests for the API built-in [part two](https://www.oriechinedu.com/posts/performing-crud-with-sequelize/). In this part, we'll be focusing on integrating Travis CI and Coveralls which automates the running of the test when we push code to the repository thereby ensuring that new code to the codebase meets a given specification before integration.

### Explanation of terms

- **Continuous Integration (CI)** - Continuous integration is a software development practice whereby the integration of new code changes to the codebase is automated using some tools such as Travis CI, Circle CI, etc. It ensures that an incoming change does not break the application. CI tools run an automated test and assert that the new code is correct before integration.

- **Continuous Delivery (CD)** - Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. - [_atlassian.com_](https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment).

- [**Travis CI**](https://docs.travis-ci.com) - a continuous integration platform which supports the development process by automatically building and testing code changes, providing immediate feedback on the success of the change. -[_docs_](https://docs.travis-ci.com/user/for-beginners/)
- [**Coveralls**](https://docs.coveralls.io/) - a language-agnostic and CI-agnostic web service to help track code coverage over time, and ensure that all your new code is fully covered. - [_docs_](https://docs.coveralls.io/)

### Getting Started

To follow along, clone the project used in the previous articles [here](git@github.com:oriechinedu/sequelize-with-postgres-tutorial.git). Or if you already have a project that you want to add CI, open it in your favorite text editor.

## Integrating Travis CI

The first step is to link the project repository to your [`Travis account`](https://docs.travis-ci.com). If you don't have Travis account, you can quickly sign up using your GitHub account. Follow the gif image below to link your repo to Travis CI:

![Gif image showing how to link a repository to Travis CI](https://thepracticaldev.s3.amazonaws.com/i/vjieg7ghd0xcnljg8wcq.gif)

![Gif image showing how to add environment variables and copy travis badge](https://thepracticaldev.s3.amazonaws.com/i/4i2kra27z8m6yg3jyp8i.gif)

The gif images above demo the processes involved in integrating a repo to travis CI. The first image shows how to add the repo and activate it on Travis CI. The second image shows how to add environmental variables that the test might require to work if any. The last part of the second image shows how to generate the `Travis build badge`. Copy the markdown generated and add to the project readme, it should look as shown below:

[![Build Status](https://travis-ci.org/oriechinedu/sequelize-with-postgres-tutorial.svg?branch=master)](https://travis-ci.org/oriechinedu/sequelize-with-postgres-tutorial)

Next up, we need to create a file called `.travis.yml`. The `.travis.yml` contains commands required for Travis CI to work.

On the project root directory, run the command below:

```
touch .travis.yml
```

Copy the following code into the `.travis.yml`:

```yaml
language: node_js
node_js:
  - 'stable'
install: npm install
services:
  - postgresql
before_script:
  - psql -c 'create database test_db;' -U postgres
script: npm test
after_success: npm run coverage
```
Looking at the `.travis.yml`, the first line specifies the language the test is written. The second line tells Travis to use a stable version of node.js. Travis CI provides its own database, all we need to do is to tell Travis the type of database we need, which is done in the `services`. The `before_script` tells Travis to create a database `test_db`. The `after_success` tells Travis to run the coverage test and send the coverage report only if the test passes.

## Integrating Coveralls

To integrate the project repository to coveralls, we will follow similar steps as integrating Travis CI. Log in to [coveralls.io](https://docs.coveralls.io/) with your Github account. Take a look at the gif images below for a guide on adding the repository to coveralls.

![Gif image showing how to link repo to coveralls.io](https://thepracticaldev.s3.amazonaws.com/i/uuqa1n3p1b7zof9tx6ai.gif)

![Gif image showing how to copy the coverage badge](https://thepracticaldev.s3.amazonaws.com/i/a328nz6ygpm9h7cywyt7.gif)

Next up, copy the coverage badge and add to the project readme. It looks as shown below:
[![Coverage Status](https://coveralls.io/repos/github/oriechinedu/sequelize-with-postgres-tutorial/badge.svg?branch=master)](https://coveralls.io/github/oriechinedu/sequelize-with-postgres-tutorial?branch=master)

If you want to send the coverage report each time the test runs locally, then create a file named `.coveralls.yml`, copy the `repo_token` found on the project dashboard on coveralls and add to it. Note that the `repo_token` is optional for public repositories.


Next up, we need to create the `coverage` script. To do so, copy the code below and add to the `scripts` in package.json.

```json
 "coverage": "npm run pretest && jest --coverage && cat ./coverage/lcov.info | coveralls"
```

Next up, install the coveralls package.

```
npm install --save-dev coveralls
```

Now, run the coverage test:

```
npm run coverage
```

If you have the `repo_token` inside the `.coveralls.yml`, you'd notice that the coverage badge has updated as you can see above which initially says `Coverage Unknown`.

Finally, we need to push the changes to the repository, if everything is alright, Travis will be triggered immediately the code is pushed and if the test runs successfully, the build badge will be updated to `build passing`.

And voila! the image below shows that the build is passing:
![Image showing that build is passing](https://thepracticaldev.s3.amazonaws.com/i/w1hb13yq3i67jawqoizo.png)

### How to check the uncovered areas
Notice that when you ran the command, `npm run coverage`, a folder called `coverage` is generated, that folder contains the coverage information which is sent to the coverage reporter in this case, coveralls. 

There is also an HTML file inside the `coverage` at `coverage/lcov-report/index.html`. This file contains visual information of the line of codes covered and uncovered by the test. This comes in handy when you want to know where exactly you need to focus to improve the test coverage. A sample image of the `coverage/lcov-report/index.html` is shown below:

![screenshot of coverage report html](https://thepracticaldev.s3.amazonaws.com/i/rq8h4mrpsyy5dzru91fq.png)

You can click on each of the rows to expand it for more details.

### Conclusion
We have integrated Travis CI and Coveralls successfully. Now, assuming there are several developers contributing to the codebase, the integration checks that the incoming change is safe and does not break the existing codebase.

Next up, you can set your auto-deploy to run once the test passes, that way, you don't need to manually deploy each time there's a new change to the codebase. That is CI/CD in action.

I may not have touched every bit of this topic but be rest assured that I am available to answer your question should if any. Feel free to reach out to me for more discussions on this topic.

#### Additional links

- [Travis Ci Docs](https://docs.travis-ci.com/user/database-setup/)
- [node Coveralls](https://github.com/nickmerwin/node-coveralls)
- [Continuous integration vs. continuous delivery vs. continuous deployment](https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment)