Javascript

Introduction to Testing in Node.js with Mocha and Chai

Apr 21, 2021

5 min read

When writing software, it can be tedious to test features manually and ensure your entire program continues to work as it evolves over time. We can use automated testing to invoke our program automatically, and ensure it works as expected.

The Purpose of Testing

Simply put, writing good tests that verify your program works as expected will help you catch regressions, and improve the reliability of your software. Good tests will ensure the program meets the requirements the program needs to meet, and that it will continue to do so as the program evolves over time. Software testing is also integral to some software development processes like TDD and BDD, though these are outside the scope of this article.

The Node.js ecosystem has a large variety of testing frameworks to choose from, and many serve many different purposes. We'll be focusing on using Mocha and Chai to demonstrate the basics of testing in the context of backend development.

What are Mocha and Chai?

Mocha is a JavaScript testing framework that runs on Node.js, and in the browser. It is one of the most popular test frameworks in use in the Node.js community, and is very easy to learn and understand.

Chai is an assertion library that helps extend test frameworks like Mocha to make writing certain kinds of tests easier. Most test frameworks like Mocha also come with their own assertion functions as well, but we've opted to show off Chai since it makes it easier to write more complex tests.

Installing Mocha and Friends

Mocha and Chai can be installed into your project using the following:

npm install mocha chai --save-dev

Also, note that all following examples are available on GitHub for your viewing pleasure. I won't be showing all code being tested in this article as it would be a lot. You can then define a scripts section in your package.json file to run your tests so you can run your tests with npm test.

{
  "name": "mocha-basic",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "mocha"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "mocha": "^8.3.2"
  }
}

The Basics

We will start by showing off one of the most basic tests that you can make with Mocha, and bear with me as I'll show off some more complex tests later. This is a basic unit test that calls a function that returns the number 42, and tests that the result comes back as expected. The following is defined in a file called index.js.

exports.meaningOfLife = () => {
  return 42;
};

And the test for this function can be written as follows in a file located at test/index.test.js (note the naming convention).

const assert = require("assert");

const { meaningOfLife } = require("../index");

describe("Index", function () {
  describe("#meaningOfLife", function () {
    it("should return 42", function () {
      const result = meaningOfLife();
      assert.strictEqual(result, 42);
    });
  });
});

Tests can be run by invoking npm test in your project root. I've opted to keep all tests in a directory called test under the project root, and have test files for each corresponding source file with an added test.js suffix at the end of the filename. There are a few layers to this test, so let's go through each one.

Tests are defined by calling global Mocha functions that are defined when the mocha command is invoked. describe is used for organizing your tests. The way that I'm using it above is one level for what I'm testing in general, this being the index file, the meaningOfLife function, and then all tests that need to invoke that function. In this case there's only one test since this is a very simple function.

Tests are written inside of callbacks passed into the it function. One thing to note is how the test reads out like plain English. This is meant to make the purpose of the test to be more clear to the reader. In this example, we simply import and call the meaningOfLife function and check that it equals 42. We also use the assert call from Mocha to do this comparison, as it will raise an exception if the two expressions don't match.

Let's test an API

To demonstrate more practical tests, I've opted to create a basic API that returns data, and tests that the data has the expected format. The API is a simple express application that returns an array of movies as JSON by calling GET /movies against it.

Testing an API isn't as simple as calling a function, and checking a response, so we will use chai and supertest to help us. The tests are as follows:

const chai = require("chai");
const request = require("supertest");

const expect = chai.expect;
const app = require("../../app");

describe("Movies", function () {
  describe("GET /movies", function () {
    it("should return 200 OK with several movies", async function () {
      const response = await request(app)
        .get("/movies")
        .expect(200)
        .expect("Content-Type", /json/);

      const movies = response.body;
      expect(movies).to.be.an("array");
      expect(movies).length.to.be.greaterThan(0);
    });

    it("should have valid movies", async function () {
      const response = await request(app)
        .get("/movies")
        .expect(200)
        .expect("Content-Type", /json/);

      const movies = response.body;
      expect(movies).to.be.an("array");

      movies.forEach(movie => {
        expect(movie.name).to.be.a("string");
        expect(movie.year).to.be.a("number");
        expect(movie.rating).to.be.a("number");
        expect(movie.description).to.be.a("string");
        expect(movie.director).to.be.a("string");
        expect(movie.genres).to.be.an("array");
      });
    });
  });
});

Chai, as mentioned before, is an assertion library, and we use it here primarily for type checking the data coming back from the API. We use SuperTest to make API calls. We pass our app object to SuperTest, and it handles making sure the API is listening, and gives us access to some useful HTTP request builders that include assertion functions as well.

We import the expect function from Chai, and use it instead of the built-in Mocha ones. The tests read out like plain English, and are very easy to understand. Chai actually has several interfaces that allow you to write tests such as "should" and "assert". These are detailed on their website.

Hooks

Imagine that the API we're testing has a persistent database of some kind. The data stored in these database will naturally persist between tests, and this can be bad if we want tests to be reproducible. To solve this problem, we can use hooks. Hooks allow code to be run before and after test blocks.

In this case we want to use them to initialize and destroy the database the API will be using for each test to ensure the state is consistent every time a test is run, and will always have the same result.

Here is an example of the beforeEach and afterEach hooks in action.

const chai = require("chai");
const request = require("supertest");

const expect = chai.expect;
const app = require("../../app");
const db = require("../../db");

describe("Movies", function () {
  // Create the schema before each test in the describe block.
  beforeEach(async function () {
    const database = await db.database;
    await db.initDB(database);
  });

  // Drop the schema before each test in the describe block.
  afterEach(async function () {
    const database = await db.database;
    await db.resetDB(database);
  });

  describe("GET /movies", function () {
    it("should return 200 OK with several movies", async function () {
      ...
    });

    it("should have valid movies", async function () {
      ...
    });
  });

  describe("GET /movies/:id", function () {
    it("should query an individual movie", async function () {
      ...
    });
  });

  describe("POST /movies", function () {
    it("should create a new movie", async function () {
      ...
    });
  });

  describe("PATCH /movies/:id", function () {
    it("should update an existing movie", async function () {
      ...
    });
  });

  describe("DELETE /movies/:id", function () {
    it("should delete an existing movie", async function () {
      ...
    });
  });
});

I've removed the contents of the actual tests since they're a bit long, but they're in the GitHub repository if you're curious. The details of the db and app modules are outside the context of this article.

The main takeaway here is the code inside of the beforeEach hook will tell Mocha to create the database before each test, and the code in the afterEach hook will tell Mocha to destroy the database after each test. I should also mention it and describe are also hooks as well!

Mocha Hooks:

it: Defines a single test.
describe: Defines a block of tests.
before: Run only once before the first test in the describe block.
after: Run only once after the last test in the describe block.
beforeEach: Runs before every test in the describe block.
afterEach: Runs after every test in the describe block.

Conclusion

Effective use of testing libraries in Node.js like Mocha and Chai can help make it easy to write tests and make your application more reliable. The example projects used throughout this article can be found on my GitHub. I have only scratched the surface here when it comes to testing. There are also frontend testing frameworks such as Selenium and Cypress. We've actually written about Cypress on our blog as well, and you can find that here if you're curious.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Jamie Kuppens

I’m a software engineer with an interest in web development and some more esoteric things like emulator development.

@Reshurum @Reshurum

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes Introduction: Next.js, a powerful React framework, offers two essential features - Parallel Routes and Intercepting Routes - that enable developers to create highly dynamic and seamless user experiences in their applications. In this blog post, we will explore both Parallel Routes and Intercepting Routes, highlighting their functionalities, use cases, and how they can be combined to enhance application routing. What are Parallel Routes? Parallel Routes in Next.js allow the rendering of multiple pages within a shared layout. Rather than navigating to a completely separate page, Parallel Routes enable the simultaneous rendering of different pages based on certain conditions such as user roles or tab navigation. By leveraging named slots, defined using the @folder convention, multiple pages can be seamlessly integrated into a single layout, enhancing user experience and reducing code duplication. How to Use Parallel Routes: To utilize Parallel Routes in Next.js, you must define named slots for the desired pages within your application's folder structure. These slots are then passed as props to a shared parent layout component. For example, consider a social networking application where two pages, feed and notifications, must be rendered within a common layout. You can define Parallel Routes using the following structure: ` The layout component in app/layout.js will accept the @feed and @notifications slots as props and render them alongside the children prop. Here's an example of the layout component: ` It's important to note that slots do not affect the URL structure and are not considered route segments. This means the URL would be /mypage/@feed/views for a route like /mypage/views since @feed is a slot. Also, to prevent the application from rendering nothing or throwing an error, we could use the default.tsx file: ` In this example, the default.tsx file specifies the default content (or fallback) to render when none of the named slots match the current route. It acts as a catch-all for routes without a corresponding slot. Some Use Cases: *Conditional Routes:* Parallel Routes can conditionally render routes based on certain conditions, such as user roles. For example, you can render a different dashboard page for admins and users. This can be achieved by creating a layout component specific to the dashboard and checking the user role to determine which slot to render. *Tab Groups:* You can utilize Parallel Routes to create tabbed navigation within a section. This is especially useful for analytics or multi-page views. Adding a layout inside a slot allows users to navigate between different pages within that slot independently. *Loading and Error UI:* Parallel Routes can be independently streamed, allowing you to define custom error and loading states for each route. This enables better control over the user experience by providing distinct feedback for different app sections. *Modals:* Parallel Routes can be combined with Intercepting Routes to create modals with shareable URLs, preserved context on refresh, and customized navigation behavior. By intercepting certain routes and rendering them within a modal component, you can create a seamless modal experience. Understanding Intercepting Routes: Intercepting Routes in Next.js allows you to load content from another route within the current layout without changing the URL or refreshing the page. Using the (..) Convention: Intercepting routes are defined using the (..) convention, which is similar to the relative path convention ../ but for route segments. The convention allows for matching segments on the same level (.), one level above (..), two levels above (..)(..), or from the root app directory (...). For example, to intercept the photo segment from within the feed segment, you can create a (..)photo directory. Integrating Intercepting Routes with Parallel Routes - Modals: One powerful use case for Intercepting Routes is creating modals, which can be combined with Parallel Routes to solve common challenges such as making the modal content shareable through a URL, preserving context on page refresh, and handling backward and forward navigation. Let's make an example: ` Our folder structure will be: In this example, when a user clicks on a photo within the /gallery page, the route /photo/:photoId will be intercepted and rendered within the (..)photo directory, overlaying the gallery content. This means that the photo route is only one segment level higher despite being two file-system levels higher. In the example above, the path to the photo segment can use the (..) matcher since @modal is a slot and not a segment. Common Use Cases - Beyond Modals: Intercepting Routes can also be utilized in other scenarios. Some examples include opening a login modal in a top navbar while having a dedicated /login page, or opening a shopping cart in a side modal for better accessibility or creating wizards or multi-step forms within a single page. The possibilities are endless. Conclusion Next.js Parallel and Intercepting Routes offer powerful methods for enhancing the routing capabilities of your applications. With Parallel Routes, multiple pages can be seamlessly integrated within a shared layout, simplifying navigation and enhancing user experience. By incorporating Intercepting Routes, you can create dynamic overlays like modals, enabling content from different routes to be displayed within the current layout. By leveraging these features, you can unlock exciting possibilities and take your Next.js applications to new heights of user engagement....

Apr 5, 2024

3 mins

NextJSJavaScript

JSR - The cross-platform package manager for ESM

JSR - The cross-platform package manager for ESM Move over NPM, there’s a new package manager in town. JSR is a new open-source package registry for JavaScript and TypeScript. This particular release has caught my attention, and I’m excited to explore if and where JSR fits into our overflowing ecosystem. Setting the stage The JSR website has a page called Why JSR? I want to explore the _why_ a little bit further. I think that the _why_ points to JSR potentially being the future of the JavaScript ecosystem. NPM and JavaScript modules If you’ve found yourself confused about publishing and consuming packages and modules in the modern ESM era, you’re not alone. When NodeJS was created, there was no standard for JS modules. Node introduced CommonJS modules, and NPM provided a way to publish and consume these modules in our applications. It’s been years now since ES Modules became a standard and we are still in a weird module purgatory with no clear end in sight. JSR represents a fresh start, free from the baggage of the Node and NPM ecosystems. JavaScript runtimes and interoperability New JavaScript runtimes are popping up every year. WinterCG (_Web-interoperable Runtimes Community Group)_ was started to improve interoperability for the various runtimes with some standard APIs. Node has made steps towards this goal, but it might never get all the way there and NPM is coupled pretty tightly to that ecosystem. JSR supports several runtimes (depending on the package). This is a huge opportunity for it to become the package manager for the ecosystem at large. See cross-runtime support section for more details. NPM Compatibility JSR doesn’t end up being a complete departure from NPM since it includes an NPM compatibility layer. The docs highlight some limitations and provide deeper technical details on how this piece works. The simple overview is that you can install and use packages from JSR to a Node/NPM based project. The packages will get added to your package.json and node_modules directory. About the same as any package installed from NPM. JSR Overview At a high level, JSR is very similar to NPM. You can search for packages on the website. You can publish packages to their registry, and you can download packages from it as well. We touched on the two major features that set it apart from NPM: It only supports ESModules, and it has cross-runtime support. In the rest of the article we’ll explore the essentials (package management) and also some other really great features that feel like are bringing the JS package management ecosystem up to speed with our modern workflows. Native TypeScript I have to say I’m not surprised by this feature, considering JSR was developed by the same people behind Deno (a runtime that supports TS natively). It’s a great feature. If you haven’t figured it out yet TypeScript is a big deal and doesn’t seem to be fading away anytime soon. So what exactly does TS support look like in a package manager, though? If your runtime supports TypeScript natively (like Deno) - it can consume the TS files in your package directly. For environments that don’t, it will automatically compile your code to JavaScript and package it with type declaration files (.d.ts). Pretty, stinking, cool. The docs include a page called “about slow types”. It is probably worth a read on its own ,but the TLDR is that JSR will analyze your TS code and penalize you in certain ways if you have some type code that it considers to be slow. On the page, it outlines exactly what these penalties are, as well as what it considers slow types to be. Slow types will also come into play when we get into package scoring later in the article. Packages The docs have a page dedicated to packages. It covers some important stuff like deleting packages, versioning, documentation, and publishing. We’ll touch on some of it with an emphasis on the things that are done differently or better than with NPM. jsr.json file jsr.json is a configuration file that specifies a name, version, and exports of a package. It doesn’t include a list of dependencies like you would have in a package.json file. This is a configuration file for a package to be published to JSR. JSR dependencies are defined in an import map file or a package.json file, depending on the runtime. Adding packages to a project Adding packages to your project will vary depending on your target runtime. Here’s an example of installing it for Deno and NPM using various package managers. For Deno, an import map entry is created. For NPM, it gets installed as an NPM package using the JSR NPM compatibility layer. ` If the runtime has native JSR support, you don’t need to explicitly install packages. You can important them using the jsr: scheme. ` As you can see semantic versioning is supported and works similarly to NPM. Publishing packages If you want to publish a package to JSR, there are many important rules you need to be aware of. I recommend reading “Publishing packages” before moving forward with this. The main things to note are: ESModules only, npm packages are supported, JSR packages are supported, and node APIs are supported. So there aren’t many constraints. You just need to understand how exactly to do these things. IE: how do I use NPM dependencies, how do the imports work, etc? Once you’ve got all that down, you will be ready to publish your first package to JSR 😃 Documentation JSR emphasizes quality package documentation. It’s one of the factors in their package scoring algorithm, which we will discuss shortly. The important parts of a package’s documentation include: * a README.md file * symbol documentation - functions, interfaces, classes, etc * module documentation - docs for each exported module in a package The symbol and module documentation are written using JSDoc. The JSR website generates some nice documentation based on these 3 pieces on your package page. This means you can understand a package's entire public API without ever leaving jsr.io. Browser support The cross-runtime support is amazing, but I was curious where the original JavaScript runtime fit (the browser). According to the documentation: “You can use JSR with any tool that supports ES modules, and either has native support for JSR or supports npm packages using node_modules.” Since modern web browsers support ES modules, I will count this as JSR support. From what I can tell, though, there is one caveat. To include a module on a web page, we need a URL to download it from. Can we publish our package to JSR and use it to load a module via a script tag? According to the JSR usage policy, no. The “Unacceptable use” section states: “It is not acceptable to use JSR as a CDN for serving assets directly to web applications in a browser, except for development purposes.” So, it seems that this is a no-go for now. We will probably need to wait a bit for CDN services like jsdelivr to pull packages from the JSR registry, similar to what they do with NPM currently. Other notable features We’ve covered the most important bits about package management, TS support, NPM compatibility, etc. But there are still a few unique features that add an extra bit of sparkle to JSR. Scoring We mentioned earlier that documentation plays a part in a scoring algorithm. JSR analyzes all of the packages published to its registry and assigns them a score based on certain criteria: documentation, best practices, discoverability, and compatibility. This score is shown with every package listed on the website. You can also add a shiny badge to your README if you’re particularly proud of something. It’s still early on, so it’s likely this will evolve as time goes on. It’s an interesting gimmick, at the very least! Summary I am excited to have a new cross-platform compatible package manager that only supports ESM. As useful as NPM has been all these years, it carries a lot of baggage from “the olden days”. JSR’s native TypeScript support and reliance on modern standards is a breath of fresh air. It feels like I can publish a simple package without much ceremony. I’m excited to release my first package to JSR soon :)...

Apr 12, 2024

6 mins

JSRJavaScript

QR Code Scanning & Generation

QR Code Scanning & Generation with ZXing and Angular QR codes provide a very valuable way of sharing information with users, and many applications rely on them for various purposes. Common examples of places where QR codes can be useful include but are not limited to theaters, social gatherings and other booking services. Integrating QR codes can seem intimidating, but thankfully they’re not too difficult to handle with Angular and the help of a couple of robust software libraries such as ZXing. What is ZXing? ZXing, also known as “Zebra Crossing” is a software library that allows developers to easily integrate scanning many different types of 1D and 2D barcodes. This library was originally written in Java, however many ports to other languages and platforms exist, including JavaScript. There are a couple of ways to use ZXing. You could either directly use the JavaScript library, which is framework-agnostic, or you could use a framework-specific library. I’m going to demonstrate how to use ZXing to scan QR codes with the Angular version of the library called ngx-scanner specifically, which has a full-fledged scanner component that makes it somewhat easy to integrate. Let’s Scan some QR Codes with Angular! Getting ngx-scanner up and running doesn’t take much setup at all. All you have to do is add an import to ZXingScannerModule inside of the module that you will be scanning QR codes in, and add a component to your template. Below shows a real-world example of how the component would be used. ` You’ll notice a lot of observables being referenced here. I’ll go over them one by one. Let’s start with the devices subject: ` This subject has data sent to it whenever cameras have been identified by the scanning component. We want to keep track of these so that we’re able to select a camera to use. In our case we’ll just select the first camera for simplicity's sake, as you can see happens with the selectedDevice$ observable that we have bound to the [device] attribute on the scanner: ` We utilize shareReplay here so we don’t need to re-scan the devices whenever additional subscribers check what devices are available. enable$ is a simple observable that emits true whenever devices have been detected, and startCamera$ is an observable that toggles between true and false whenever data is pushed to the toggleCamera$ subject. ` The scan function from RxJs is utilized so we have the previous state and can use that to determine in which direction the stored boolean should toggle to. Finally we push successfully scanned codes to scanSuccess$ which we can then subscribe to in the template. All together the final component code should look something like this: ` If we use this component then you should get something that looks like this: Scanning QR codes is awesome, but we can also generate our own QR codes as well! Generating our own QR Codes Unfortunately the ZXing scanner component we’re using is limited to just scanning QR codes, however there is another component library called ngx-kjua that can do this. Like ZXing this component is also based off of another pre-existing library that is framework-agnostic, in this case, kjua. Fortunately kjua is very easy to use. You simply supply it a code and it will render a QR code. ` How the QR code is rendered can change. There is an optional [render] attribute that you can specify that takes a few values. You can input ‘image’, ‘canvas’ or ‘svg’. The default render mode is ‘svg’. It should be noted that ‘svg’ and ‘canvas’ render modes made copying the image more difficult, so use ‘image’ if you want to make that possible. The component code associated with this template is very small. The component using ngx-kjua has a code observable that is updated with a new random code whenever a “Generate” button is pressed. ` I’ve opted to go with the randomstring package in this case. This component could be modified to instead allow for custom codes using a textbox if you want to encode URLs or other useful values that typically go inside of QR codes. The result looks like this: Summary Thanks to projects like ZXing and kjua it is easy to integrate handling of QR codes in Angular applications, be it for scanning them or creating them. I hope this guide has helped you. You can find the full example showcasing generation and scanning of QR codes in our blog-demos repository on GitHub....

Dec 13, 2023

4 mins

Angular

6 Steps to AI Adoption: Benefits of LLMs & SLMs with Jerome Hardaway and Rob Ocel

Rob Ocel and Jerome Hardaway continue their series on AI adoption by exploring the world of AI, focusing on small language models (SLMs) and large language models (LLMs). They compare the unique capabilities of SLMs against the vast knowledge encompassed by LLMs, and highlight the transformative potential of AI in driving creativity, problem-solving, and user-centric design in technology. SLMs are designed to excel at specific tasks, offering faster processing and cost-effectiveness due to their open-source nature. These models have proven to be invaluable in sectors like finance, where data security is of utmost importance. By leveraging SLMs, organizations can enhance their security measures and protect sensitive information. Moreover, SLMs provide a stepping stone for engineers to adapt to new technologies and incorporate AI into their work, ultimately improving user experiences. On the other hand, LLMs encompass a wide range of knowledge, making them incredibly versatile. These models have the potential to transform industries by providing insights, predictions, and solutions to complex problems. With advancements in AI chip technology by tech giants like Apple, Nvidia, Google, and Meta, LLMs are becoming even more powerful and efficient. Evaluating AI models based on factors like stability and industry support is crucial to harnessing the full potential of LLMs. The conversation also addresses some ethical questions related to AI implementation. While AI brings numerous benefits, concerns about job displacement cannot be ignored. As AI continues to evolve, it is essential to strike a balance between automation and human involvement. Engineers must focus on improving AI sophistication and seamless integration into user interactions, ensuring that AI enhances human capabilities rather than replacing them. Additionally, ethical guidelines and regulations must be established to address potential biases and ensure responsible AI implementation. Download this episode here....

Apr 23, 2024

2 mins

Engineering Leadership

Introduction to Testing in Node.js with Mocha and Chai

The Purpose of Testing

What are Mocha and Chai?

Installing Mocha and Friends

The Basics

Let's test an API

Hooks

Conclusion

Jamie Kuppens

You might also like

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

JSR - The cross-platform package manager for ESM

QR Code Scanning & Generation

6 Steps to AI Adoption: Benefits of LLMs & SLMs with Jerome Hardaway and Rob Ocel

You might also like

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

JSR - The cross-platform package manager for ESM

QR Code Scanning & Generation

6 Steps to AI Adoption: Benefits of LLMs & SLMs with Jerome Hardaway and Rob Ocel