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.
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."
In this tutorial, I'll show you how to configure visualizations of Continuous Integration test results. This visualization not only looks good, but also helps a developer to drill down on tests that failed and find the root cause much quicker.
Here's how a successful Continuous Integration test result would look.
I have gone through the steps of running basic Continuous Integration (CI) on a Node.js app hosted on a private repository. Now I'll configure a visual indicator to display the status of the Node.js app when CI is run, using build badges. As shown below, I use it to update my team mates about the latest build status of my project in a convenient way.
First, what is a Badge and where is it used?
Badges, in the context of continuous integration, are used to display the meta-data of a build. For example, at the completion of a build, a status is displayed on whether a build succeeded or failed. This build status is incorporated into a build badge and can be displayed to viewers in different ways and in different locations. Badges are used to display different meta-data such as build status, code coverage percentage, status of third party dependencies, release versions, etc.
In this tutorial, I'll configure the Node.js app on Shippable to embed build status in two ways and show few examples of the outcome.
In my previous blogs, I completed running a basic Continuous Integration (CI) on a Node.js app hosted on a public repository. Next, I configured a simple unit test for the Node.js app to check for errors each time I did a code commit.
In this tutorial, I'll cover running CI for the same Node.js application, if it were hosted on a private repository. Hosting code on a private repository source control system is the common way developers/teams operate during software development. The overview of the work flow is to sign in using source control provider credentials, authorizing a one-time access to private repositories, enabling the project, configuring the
shippable.ymlfile, completing a successful CI run for the Node.js app.