Using assert.rejects() in Mocha and Node: A Complete Guide

Question

Using assert.rejects() in Mocha and Node: A Complete Guide

Following the instructions in the documentation, I attempted to use assert.rejects to test for an error message (I have Node version above v10).

However, no matter what message I specify, the test always passes. What could be causing this issue?

it("is failing when it should not", 
  async ()=> {
    let itemId = 'not an id'
    assert.rejects( 
      await ListRepo.checkById(itemId),
      {message: 'abracadabra'}                        
    )
  }
)

UPDATE: It appears that returning the assert.rejects statement solves the problem, although the reason remains unknown.

javascript promise mocha.js node-assert

Answer 1

Answer №1

After careful consideration, I have come to the realization that while the information provided above is accurate, it can be simplified for better understanding. It is indeed crucial to return a promise in order for Mocha to have something to wait for, preventing it from returning prematurely before the promise resolves or rejects. However, manually waiting for a promise may not always be the most efficient approach.

A more straightforward pattern suggested by @caub involves awaiting the promise returned by assert.rejects. To implement this pattern:

it("should fail but it's not", 
  async () => {
    let itemId = 'not an id'
    await assert.rejects( 
      ListRepo.checkById(itemId),
      {message: 'abracadabra'}                        
    )
  }
)

There are three key points to note here:

The test function itself must be marked as async.
Use await with the assert.rejects call inside the async test function. This automatically ensures that the test function returns a Promise<void>, streamlining the process and enabling easy reuse of the assert call in other parts of the codebase.
Avoid using await on the value passed into the rejects call. The input should be a promise, not an awaited value.

Answer 2

After careful consideration, I have come to the realization that while the information provided above is accurate, it can be simplified for better understanding. It is indeed crucial to return a promise in order for Mocha to have something to wait for, preventing it from returning prematurely before the promise resolves or rejects. However, manually waiting for a promise may not always be the most efficient approach.

A more straightforward pattern suggested by @caub involves awaiting the promise returned by assert.rejects. To implement this pattern:

it("should fail but it's not", 
  async () => {
    let itemId = 'not an id'
    await assert.rejects( 
      ListRepo.checkById(itemId),
      {message: 'abracadabra'}                        
    )
  }
)

There are three key points to note here:

The test function itself must be marked as async.
Use await with the assert.rejects call inside the async test function. This automatically ensures that the test function returns a Promise<void>, streamlining the process and enabling easy reuse of the assert call in other parts of the codebase.
Avoid using await on the value passed into the rejects call. The input should be a promise, not an awaited value.

Answer 3

Answer №2

What nicholaswmin mentioned is indeed accurate, however, there is a crucial "rest of the owl" moment that I would like to clarify.

If you are thinking: "I want to ensure rejection," meaning "I want to verify that this code rejects correctly," the process is a bit intricate.

To begin with, include return fxnWhichReturnsPromise(). The test will not pass if your function is rejecting, and you actually want it to fail under those circumstances. You must utilize the two-argument form of .then(), which appears as follows:

.then(onFulfillCallback, onRejectCallback)

. This is necessary because if you separate it into .then and .catch, failing in the .then block will be captured by the subsequent .catch block. Consequently, what should be a failed test (as it did not reject) will actually show as passing.

In practical application, the whole setup looks similar to this:

it('rejects when given foobar', () => {
  return fxnThatShouldReject(foobar)
    .then(
      (val) => { assert.fail(`Should have rejected, but instead returned ${val}`)
      ,
      (err) => { assert.equal(err.message, "The expected reason for rejection") }
    )
})

The reason why the assertion library lacks a pre-defined handler for this scenario is because being able to temporarily pause asynchronous execution within the test suite is essentially a feature of the test-runner. In contrast, assert.throws() operates synchronously.

Answer 4

What nicholaswmin mentioned is indeed accurate, however, there is a crucial "rest of the owl" moment that I would like to clarify.

If you are thinking: "I want to ensure rejection," meaning "I want to verify that this code rejects correctly," the process is a bit intricate.

To begin with, include return fxnWhichReturnsPromise(). The test will not pass if your function is rejecting, and you actually want it to fail under those circumstances. You must utilize the two-argument form of .then(), which appears as follows:

.then(onFulfillCallback, onRejectCallback)

. This is necessary because if you separate it into .then and .catch, failing in the .then block will be captured by the subsequent .catch block. Consequently, what should be a failed test (as it did not reject) will actually show as passing.

In practical application, the whole setup looks similar to this:

it('rejects when given foobar', () => {
  return fxnThatShouldReject(foobar)
    .then(
      (val) => { assert.fail(`Should have rejected, but instead returned ${val}`)
      ,
      (err) => { assert.equal(err.message, "The expected reason for rejection") }
    )
})

The reason why the assertion library lacks a pre-defined handler for this scenario is because being able to temporarily pause asynchronous execution within the test suite is essentially a feature of the test-runner. In contrast, assert.throws() operates synchronously.

Using assert.rejects() in Mocha and Node: A Complete Guide

Answer №1

Answer №2

Similar questions

Accessing elements within a ReactJS map structure using the material-ui Selectable List component is not supported

Anchoring HTTP headers in HTML tags

What is the best way to activate a JavaScript function once a page has finished loading?

Developing a jsp page with interconnected drop down menus

What is the best way to create three buttons for selecting various parameters?

Enhancing Animation Speed with jQuery

React Navigation Item Toolbar Misplacement

ReactJS encountered an error of type ERR_INVALID_ARG_TYPE

fnRedraw and fnReloadAjax do not have the capability to refresh the datatable

Implementation issue with Hashids library in Vue.js causing functionality hiccups

Displaying a hand cursor on a bar chart when hovered over in c3.js

Maintain checkbox selection even after the page is refreshed

Am I on the right track with incorporating responsiveness in my React development practices?

What could be causing my Bootstrap modal to fail to load dynamically?

Tips for displaying the sum of a grouped field in the balloonText using Amchart

Ways to efficiently display elements in a grid in real-time

The Chrome developer tools are unable to locate the HttpRequest

Best Practices for Making Remote Requests in Ruby on Rails

JavaScript: function that operates asynchronously

switching the image source by selecting different options from a dropdown menu and leveraging JavaScript