The Shippable Blog

How to test your Node.js app against multiple versions of Node

Software applications are regularly updated primarily to add new features, resolve bugs in the code and for security enhancements. A development language is no exception and each major update is called as a version. While it is a great advantage to have newer features, lesser issues and stronger security, the challenge arises when complexity creeps in. With multiple versions of a language, applications that depend on them have to be compatible with many versions. Moreover, when the applications themselves have to be updated, the combination of different versions of the language and the application makes it a challenge to write and test code.

Testing code against multiple versions of a language early in the application delivery life cycle helps in fixing errors quickly and makes testing more efficient in the downstream of the life cycle. In this tutorial, I'll go through testing a Node.js application against multiple versions of Node.js for every code commit during the continuous integration phase of the software development life cycle.

How to link GitHub and Bitbucket accounts

Two among the most popular source control providers are GitHub and Bitbucket. Both these providers offer free repositories and it is not uncommon for software teams to have few of their projects on GitHub and few others on Bitbucket. So if you are a developer who has accounts with both GitHub/Bitbucket and looking to run Continuous Integration on projects hosted on both of these source control providers, this tutorial will help you acheive it in an easy way.

First, let's take a brief look at how source control providers are used. Software developers use web-based, hosted source code systems for software projects, to leverage functions such as distributed revision control, bug tracking, source code management and wiki-based documentation. The source code repositories store large amounts of software source code, kept either publicly (for open source projects) or privately and enable multiple developers to collaborate on the code.

Automatically retry scripts to avoid network hiccups during CI process

Sometimes intermittent network issues happen to the best of us, and it is particularly frustrating if it happens in the middle of a software install.

Notifying Continuous Integration failure/success status on Email & Slack

Notifications are particularly useful when you start hitting scale with the number of software projects that are being worked on in parallel. Having the flexibility to configure the Continuous Integration platform to be notified for different scenarios becomes critical, in my opinion, in helping to reduce technical debt

At Shippable, we use Slack extensively for our internal communications. It allows us to be more efficient, communicate faster and have targeted discussions. One of the scenarios we use Slack is to monitor and discuss build issues based on the build status of critical projects. An example shown below.

 

In this tutorial, I'll pick three scenarios and go over configuring notifications for a Continuous Integration project status on email and Slack. First I'll go over the basics of the shippable.yml file configuration for email/Slack notifications. Then I'll cover the scenarios for email and Slack.

Setting up code coverage for tests in Continuous Integration

I set up Continuous Integration (CI) test results visualization, in the previous tutorial. In this one, I'll set up code coverage visualization for the CI project.

What is Code coverage and why is it useful?

Code coverage is a measure used to describe the degree to which a source code of a program is tested using a particular test suite. In other words, it tells you the percentage of your code that is being tested. It is used as a guide to write more comprehensive tests to parts of your code. 

In practice, developers use it as part of exit criteria for milestons, to write tests for untested parts of  code, review developers have written good unit tests, etc.

While it is useful, one should remember not to use it as the only value to determine the quality of your code. In the words of Martin Fowler "Test coverage (also called code coverage) is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are."