Skip to main content
Redhat Developers  Logo
  • Products

    Platforms

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat AI
      Red Hat AI
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • View All Red Hat Products

    Featured

    • Red Hat build of OpenJDK
    • Red Hat Developer Hub
    • Red Hat JBoss Enterprise Application Platform
    • Red Hat OpenShift Dev Spaces
    • Red Hat OpenShift Local
    • Red Hat Developer Sandbox

      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Secure Development & Architectures

      • Security
      • Secure coding
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • Product Documentation
    • API Catalog
    • Legacy Documentation
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Introduction to the Node.js reference architecture, Part 7: Code coverage

 

March 2, 2022
Lucas Holmquist
Related topics:
Kubernetes
Related products:
Red Hat OpenShift

Share:

    In this article, we'll look at why testing in JavaScript applications is important. You'll also learn how to measure code coverage, how to maximize your investment in testing, and what the Node.js reference architecture recommends to ensure adequate code coverage.

    Read the other articles in our Node.js reference architecture series:

    • Part 1: Overview of the Node.js reference architecture
    • Part 2: Logging in Node.js
    • Part 3: Code consistency in Node.js
    • Part 4: GraphQL in Node.js
    • Part 5: Building good containers
    • Part 6: Choosing web frameworks
    • Part 7: Code coverage
    • Part 8: Typescript
    • Part 9: Securing Node.js applications
    • Part 10: Accessibility
    • Part 11: Typical development workflows
    • Part 12: npm development
    • Part 13: Problem determination
    • Part 14: Testing
    • Part 15: Transaction handling
    • Part 16: Load balancing, threading, and scaling
    • Part 17: CI/CD best practices in Node.js
    • Part 18: Wrapping up

    What is code coverage?

    Code coverage is a software testing metric that determines how much code in a project has been successfully validated under a test procedure, which in turn, helps in analyzing how thoroughly software has been verified.

    To measure the lines of code that are actually exercised by test runs, the code coverage metric takes various criteria into consideration. The following are a few important coverage criteria.

    • Function coverage: The functions in the source code that are called and executed at least once.
    • Statement coverage: The number of statements that have been successfully validated in the source code.
    • Path coverage: The flows containing a sequence of controls and conditions that have worked well at least once.
    • Branch or decision coverage: The decision control structures (loops, for example) that have executed properly.
    • Condition coverage: The Boolean expressions that are validated and that execute both TRUE and FALSE during the test runs.
    • Condition coverage: The Boolean expressions that are validated and that execute both TRUE and FALSE during the test runs.
    • Condition coverage: The Boolean expressions that are validated and that execute both TRUE and FALSE during the test runs.

    What modules should you use for code coverage?

    If you've read the previous installments in the Node.js reference architecture series, you know that we recommend modules that our teams are familiar with and use regularly. This article is no different. The teams defining the reference architecture have decided on two modules that we recommend for code coverage:

    • nyc, probably the most popular tool for code coverage. One of the main reasons this module is the most popular is that it works well with most JavaScript testing frameworks. nyc is the successor command-line interface (CLI) for istanbul.
    • Jest, which generates coverage when you run the tool with the --coverage option.

    This article's examples use nyc.

    Testing example

    Download the example from the Nodeshift example repository. The example is made up of two simple functions located in the index.js file, and a test in the test directory that uses the Mocha test runner.

    The first function adds two numbers:

    function addTwoNumbers(x, y) {
    
      return x + y;
    
    }

    This function can be easily covered by this simple test:

    describe('testing for coverage', () => {
    
      it ('should add 2 numbers correctly', () => {
    
        assert.equal(addTwoNumbers(1,1), 2);
    
      });
    
    });

    Code coverage can be generated easily too: Just call the nyc module in conjunction with our test to generate the coverage report.

    The package.json might look something like this to run our tests while generating coverage reports:

    "scripts": {
    
        "test": "mocha",
    
        "coverage": "nyc npm run test"
    
      }

    Executing npm run coverage is all that is needed. Because we wrote only one test, our statement coverage will be only about 18%. To increase code coverage, we have to test the other functions  and statements:

      testing for coverage
    
        ✔ should add 2 numbers correctly
    
    
    
    
      1 passing (3ms)
    
    
    
    ----------|---------|----------|---------|---------|-------------------
    
    File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
    
    ----------|---------|----------|---------|---------|-------------------
    
    All files |   18.18 |        0 |      50 |   18.18 |
    
     index.js |   18.18 |        0 |      50 |   18.18 | 9-23
    
    ----------|---------|----------|---------|---------|-------------------
    

    Once the other tests are written and run, code coverage should be at 100%:

    testing for coverage
    
        ✔ should add 2 numbers correctly
    
        ✔ should test that phish is the best band
    
        ✔ should test the beatles are a good band too
    
        ✔ should test that nickelback is not that good
    
        ✔ should test that all other bands are pretty good
    
    
    
    
      5 passing (6ms)
    
    
    
    ----------|---------|----------|---------|---------|-------------------
    
    File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
    
    ----------|---------|----------|---------|---------|-------------------
    
    All files |     100 |      100 |     100 |     100 |
    
     index.js |     100 |      100 |     100 |     100 |
    
    ----------|---------|----------|---------|---------|-------------------

    What to cover

    After much discussion, the reference architecture team's guidance on what to cover is broken down into two sections:

    • Coverage for modules: It is important to cover all public APIs. Basically, any exposed API that a user can interact with should be covered.
    • Coverage for applications: This coverage should be driven by the key user stories and key paths that the application can take. Unlike a module, here it is much more important to test and cover paths that are critical for your application than to worry about covering all paths.

    Acceptable coverage thresholds

    We realized in our discussions that not all projects are created equal. Some projects might be starting from scratch, whereas others contain legacy code bases.

    For new projects without legacy code, a good percentage threshold is about 70%. This is because, with new projects, it is relatively easy to add tests while creating the application or module.

    It might be a little harder to add coverage to a project that is older and doesn't have any coverage yet, because adding tests to old code with technical debt can be a challenge, especially for someone new coming into the project. In this case, a good percentage threshold is about 30%.

    It is also our experience that when adding coverage to an older code base, focusing on the key user stories gives you the best return on your investment. Focusing on the path and branch/decision coverage can also maximize the investment required to get to 30%.

    Guidance for open source projects

    For free and open source projects, it might be helpful to post the results of the coverage to an external service, such as Coveralls. Creating issues that suggest ways to increase code coverage could be a way to attract contributors to the project.

    It is also common to report the coverage increase or decrease percentage during a pull request or merge request CI run. In our experience, it is best to use this information in a code review rather than by blocking a merge.

    What's next?

    We cover new topics regularly as part of the Node.js reference architecture series. In the next installment, we discuss our experience with using both plain JavaScript and TypeScript.

    We invite you to visit the Node.js reference architecture repository on GitHub, where you'll see the work we've already done and the kinds of topics you can look forward to in the future.

    To learn more about what Red Hat is up to on the Node.js front, check out our Node.js topic page.

    Last updated: January 9, 2024

    Related Posts

    • Introduction to the Node.js reference architecture, Part 6: Choosing web frameworks

    • How to build good containers in Node.js

    • Why we developed the Node.js reference architecture

    • Introduction to the Node.js reference architecture, Part 4: GraphQL in Node.js

    • Introduction to the Node.js reference architecture, Part 3: Code consistency

    Recent Posts

    • Staying ahead of artificial intelligence threats

    • Strengthen privacy and security with encrypted DNS in RHEL

    • How to enable Ansible Lightspeed intelligent assistant

    • Why some agentic AI developers are moving code from Python to Rust

    • Confidential VMs: The core of confidential containers

    What’s up next?

    10 tips for nodejs cheat sheet tile card

    Run secure and efficient Node.js applications on OpenShift and other container environments. This cheat sheet rounds up 10 tips to help you learn best practices and get up to speed quickly.

    Get the cheat sheet
    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2025 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue