Test runner#

History
VersionChanges
v20.0.0

The test runner is now stable.

v18.0.0, v16.17.0

Added in: v18.0.0, v16.17.0

Stability: 2 - Stable

Source Code:lib/test.js

Thenode:test module facilitates the creation of JavaScript tests.To access it:

import testfrom'node:test';const test =require('node:test');

This module is only available under thenode: scheme.

Tests created via thetest module consist of a single function that isprocessed in one of three ways:

  1. A synchronous function that is considered failing if it throws an exception,and is considered passing otherwise.
  2. A function that returns aPromise that is considered failing if thePromise rejects, and is considered passing if thePromise fulfills.
  3. A function that receives a callback function. If the callback receives anytruthy value as its first argument, the test is considered failing. If afalsy value is passed as the first argument to the callback, the test isconsidered passing. If the test function receives a callback function andalso returns aPromise, the test will fail.

The following example illustrates how tests are written using thetest module.

test('synchronous passing test',(t) => {// This test passes because it does not throw an exception.  assert.strictEqual(1,1);});test('synchronous failing test',(t) => {// This test fails because it throws an exception.  assert.strictEqual(1,2);});test('asynchronous passing test',async (t) => {// This test passes because the Promise returned by the async// function is settled and not rejected.  assert.strictEqual(1,1);});test('asynchronous failing test',async (t) => {// This test fails because the Promise returned by the async// function is rejected.  assert.strictEqual(1,2);});test('failing test using Promises',(t) => {// Promises can be used directly as well.returnnewPromise((resolve, reject) => {setImmediate(() => {reject(newError('this will cause the test to fail'));    });  });});test('callback passing test',(t, done) => {// done() is the callback function. When the setImmediate() runs, it invokes// done() with no arguments.setImmediate(done);});test('callback failing test',(t, done) => {// When the setImmediate() runs, done() is invoked with an Error object and// the test fails.setImmediate(() => {done(newError('callback failure'));  });});

If any tests fail, the process exit code is set to1.

Subtests#

The test context'stest() method allows subtests to be created.It allows you to structure your tests in a hierarchical manner,where you can create nested tests within a larger test.This method behaves identically to the top leveltest() function.The following example demonstrates the creation of atop level test with two subtests.

test('top level test',async (t) => {await t.test('subtest 1',(t) => {    assert.strictEqual(1,1);  });await t.test('subtest 2',(t) => {    assert.strictEqual(2,2);  });});

Note:beforeEach andafterEach hooks are triggeredbetween each subtest execution.

In this example,await is used to ensure that both subtests have completed.This is necessary because tests do not wait for their subtests tocomplete, unlike tests created within suites.Any subtests that are still outstanding when their parent finishesare cancelled and treated as failures. Any subtest failures cause the parenttest to fail.

Skipping tests#

Individual tests can be skipped by passing theskip option to the test, or bycalling the test context'sskip() method as shown in thefollowing example.

// The skip option is used, but no message is provided.test('skip option', {skip:true },(t) => {// This code is never executed.});// The skip option is used, and a message is provided.test('skip option with message', {skip:'this is skipped' },(t) => {// This code is never executed.});test('skip() method',(t) => {// Make sure to return here as well if the test contains additional logic.  t.skip();});test('skip() method with message',(t) => {// Make sure to return here as well if the test contains additional logic.  t.skip('this is skipped');});

Rerunning failed tests#

The test runner supports persisting the state of the run to a file, allowingthe test runner to rerun failed tests without having to re-run the entire test suite.Use the--test-rerun-failures command-line option to specify a file path where thestate of the run is stored. if the state file does not exist, the test runner willcreate it.the state file is a JSON file that contains an array of run attempts.Each run attempt is an object mapping successful tests to the attempt they have passed in.The key identifying a test in this map is the test file path, with the line and column where the test is defined.in a case where a test defined in a specific location is run multiple times,for example within a function or a loop,a counter will be appended to the key, to disambiguate the test runs.note changing the order of test execution or the location of a test can lead the test runnerto consider tests as passed on a previous attempt,meaning--test-rerun-failures should be used when tests run in a deterministic order.

example of a state file:

[{"test.js:10:5":{"passed_on_attempt":0,"name":"test 1"}},{"test.js:10:5":{"passed_on_attempt":0,"name":"test 1"},"test.js:20:5":{"passed_on_attempt":1,"name":"test 2"}}]

in this example, there are two run attempts, with two tests defined intest.js,the first test succeeded on the first attempt, and the second test succeeded on the second attempt.

When the--test-rerun-failures option is used, the test runner will only run tests that have not yet passed.

node --test-rerun-failures /path/to/state/file

TODO tests#

Individual tests can be marked as flaky or incomplete by passing thetodooption to the test, or by calling the test context'stodo() method, as shownin the following example. These tests represent a pending implementation or bugthat needs to be fixed. TODO tests are executed, but are not treated as testfailures, and therefore do not affect the process exit code. If a test is markedas both TODO and skipped, the TODO option is ignored.

// The todo option is used, but no message is provided.test('todo option', {todo:true },(t) => {// This code is executed, but not treated as a failure.thrownewError('this does not fail the test');});// The todo option is used, and a message is provided.test('todo option with message', {todo:'this is a todo test' },(t) => {// This code is executed.});test('todo() method',(t) => {  t.todo();});test('todo() method with message',(t) => {  t.todo('this is a todo test and is not treated as a failure');thrownewError('this does not fail the test');});

Expecting tests to fail#

Added in: v25.5.0

This flips the pass/fail reporting for a specific test or suite: A flagged test/test-case must throwin order to "pass"; a test/test-case that does not throw, fails.

In the following,doTheThing() returnscurrentlyfalse (false does not equaltrue, causingstrictEqual to throw, so the test-case passes).

it.expectFailure('should do the thing',() => {  assert.strictEqual(doTheThing(),true);});it('should do the thing', {expectFailure:true },() => {  assert.strictEqual(doTheThing(),true);});

skip and/ortodo are mutually exclusive toexpectFailure, andskip ortodowill "win" when both are applied (skip wins against both, andtodo winsagainstexpectFailure).

These tests will be skipped (and not run):

it.expectFailure('should do the thing', {skip:true },() => {  assert.strictEqual(doTheThing(),true);});it.skip('should do the thing', {expectFailure:true },() => {  assert.strictEqual(doTheThing(),true);});

These tests will be marked "todo" (silencing errors):

it.expectFailure('should do the thing', {todo:true },() => {  assert.strictEqual(doTheThing(),true);});it.todo('should do the thing', {expectFailure:true },() => {  assert.strictEqual(doTheThing(),true);});

describe() andit() aliases#

Suites and tests can also be written using thedescribe() andit()functions.describe() is an alias forsuite(), andit() is analias fortest().

describe('A thing',() => {it('should work',() => {    assert.strictEqual(1,1);  });it('should be ok',() => {    assert.strictEqual(2,2);  });describe('a nested thing',() => {it('should work',() => {      assert.strictEqual(3,3);    });  });});

describe() andit() are imported from thenode:test module.

import { describe, it }from'node:test';const { describe, it } =require('node:test');

only tests#

If Node.js is started with the--test-only command-line option, or testisolation is disabled, it is possible to skip all tests except for a selectedsubset by passing theonly option to the tests that should run. When a testwith theonly option is set, all subtests are also run.If a suite has theonly option set, all tests within the suite are run,unless it has descendants with theonly option set, in which case only thosetests are run.

When usingsubtests within atest()/it(), it is required to markall ancestor tests with theonly option to run only aselected subset of tests.

The test context'srunOnly()method can be used to implement the same behavior at the subtest level. Teststhat are not executed are omitted from the test runner output.

// Assume Node.js is run with the --test-only command-line option.// The suite's 'only' option is set, so these tests are run.test('this test is run', {only:true },async (t) => {// Within this test, all subtests are run by default.await t.test('running subtest');// The test context can be updated to run subtests with the 'only' option.  t.runOnly(true);await t.test('this subtest is now skipped');await t.test('this subtest is run', {only:true });// Switch the context back to execute all tests.  t.runOnly(false);await t.test('this subtest is now run');// Explicitly do not run these tests.await t.test('skipped subtest 3', {only:false });await t.test('skipped subtest 4', {skip:true });});// The 'only' option is not set, so this test is skipped.test('this test is not run',() => {// This code is not run.thrownewError('fail');});describe('a suite',() => {// The 'only' option is set, so this test is run.it('this test is run', {only:true },() => {// This code is run.  });it('this test is not run',() => {// This code is not run.thrownewError('fail');  });});describe.only('a suite',() => {// The 'only' option is set, so this test is run.it('this test is run',() => {// This code is run.  });it('this test is run',() => {// This code is run.  });});

Filtering tests by name#

The--test-name-pattern command-line option can be used to only runtests whose name matches the provided pattern, and the--test-skip-pattern option can be used to skip tests whose namematches the provided pattern. Test name patterns are interpreted asJavaScript regular expressions. The--test-name-pattern and--test-skip-pattern options can be specified multiple times in order to runnested tests. For each test that is executed, any corresponding test hooks,such asbeforeEach(), are also run. Tests that are not executed are omittedfrom the test runner output.

Given the following test file, starting Node.js with the--test-name-pattern="test [1-3]" option would cause the test runner to executetest 1,test 2, andtest 3. Iftest 1 did not match the test namepattern, then its subtests would not execute, despite matching the pattern. Thesame set of tests could also be executed by passing--test-name-patternmultiple times (e.g.--test-name-pattern="test 1",--test-name-pattern="test 2", etc.).

test('test 1',async (t) => {await t.test('test 2');await t.test('test 3');});test('Test 4',async (t) => {await t.test('Test 5');await t.test('test 6');});

Test name patterns can also be specified using regular expression literals. Thisallows regular expression flags to be used. In the previous example, startingNode.js with--test-name-pattern="/test [4-5]/i" (or--test-skip-pattern="/test [4-5]/i")would matchTest 4 andTest 5 because the pattern is case-insensitive.

To match a single test with a pattern, you can prefix it with all its ancestortest names separated by space, to ensure it is unique.For example, given the following test file:

describe('test 1',(t) => {it('some test');});describe('test 2',(t) => {it('some test');});

Starting Node.js with--test-name-pattern="test 1 some test" would matchonlysome test intest 1.

Test name patterns do not change the set of files that the test runner executes.

If both--test-name-pattern and--test-skip-pattern are supplied,tests must satisfyboth requirements in order to be executed.

Extraneous asynchronous activity#

Once a test function finishes executing, the results are reported as quicklyas possible while maintaining the order of the tests. However, it is possiblefor the test function to generate asynchronous activity that outlives the testitself. The test runner handles this type of activity, but does not delay thereporting of test results in order to accommodate it.

In the following example, a test completes with twosetImmediate()operations still outstanding. The firstsetImmediate() attempts to create anew subtest. Because the parent test has already finished and output itsresults, the new subtest is immediately marked as failed, and reported laterto the<TestsStream>.

The secondsetImmediate() creates anuncaughtException event.uncaughtException andunhandledRejection events originating from a completedtest are marked as failed by thetest module and reported as diagnosticwarnings at the top level by the<TestsStream>.

test('a test that creates asynchronous activity',(t) => {setImmediate(() => {    t.test('subtest that is created too late',(t) => {thrownewError('error1');    });  });setImmediate(() => {thrownewError('error2');  });// The test finishes after this line.});

Watch mode#

Added in: v19.2.0, v18.13.0

Stability: 1 - Experimental

The Node.js test runner supports running in watch mode by passing the--watch flag:

node --test --watch

In watch mode, the test runner will watch for changes to test files andtheir dependencies. When a change is detected, the test runner willrerun the tests affected by the change.The test runner will continue to run until the process is terminated.

Global setup and teardown#

Added in: v24.0.0

Stability: 1.0 - Early development

The test runner supports specifying a module that will be evaluated before all tests are executed andcan be used to setup global state or fixtures for tests. This is useful for preparing resources or setting upshared state that is required by multiple tests.

This module can export any of the following:

  • AglobalSetup function which runs once before all tests start
  • AglobalTeardown function which runs once after all tests complete

The module is specified using the--test-global-setup flag when running tests from the command line.

// setup-module.jsasyncfunctionglobalSetup() {// Setup shared resources, state, or environmentconsole.log('Global setup executed');// Run servers, create files, prepare databases, etc.}asyncfunctionglobalTeardown() {// Clean up resources, state, or environmentconsole.log('Global teardown executed');// Close servers, remove files, disconnect from databases, etc.}module.exports = { globalSetup, globalTeardown };// setup-module.mjsexportasyncfunctionglobalSetup() {// Setup shared resources, state, or environmentconsole.log('Global setup executed');// Run servers, create files, prepare databases, etc.}exportasyncfunctionglobalTeardown() {// Clean up resources, state, or environmentconsole.log('Global teardown executed');// Close servers, remove files, disconnect from databases, etc.}

If the global setup function throws an error, no tests will be run and the process will exit with a non-zero exit code.The global teardown function will not be called in this case.

Running tests from the command line#

The Node.js test runner can be invoked from the command line by passing the--test flag:

node --test

By default, Node.js will run all files matching these patterns:

  • **/*.test.{cjs,mjs,js}
  • **/*-test.{cjs,mjs,js}
  • **/*_test.{cjs,mjs,js}
  • **/test-*.{cjs,mjs,js}
  • **/test.{cjs,mjs,js}
  • **/test/**/*.{cjs,mjs,js}

Unless--no-strip-types is supplied, the followingadditional patterns are also matched:

  • **/*.test.{cts,mts,ts}
  • **/*-test.{cts,mts,ts}
  • **/*_test.{cts,mts,ts}
  • **/test-*.{cts,mts,ts}
  • **/test.{cts,mts,ts}
  • **/test/**/*.{cts,mts,ts}

Alternatively, one or more glob patterns can be provided as thefinal argument(s) to the Node.js command, as shown below.Glob patterns follow the behavior ofglob(7).The glob patterns should be enclosed in double quotes on the command line toprevent shell expansion, which can reduce portability across systems.

node --test"**/*.test.js""**/*.spec.js"

Matching files are executed as test files.More information on the test file execution can be foundin thetest runner execution model section.

Test runner execution model#

When process-level test isolation is enabled, each matching test file isexecuted in a separate child process. The maximum number of child processesrunning at any time is controlled by the--test-concurrency flag. If thechild process finishes with an exit code of 0, the test is considered passing.Otherwise, the test is considered to be a failure. Test files must be executableby Node.js, but are not required to use thenode:test module internally.

Each test file is executed as if it was a regular script. That is, if the testfile itself usesnode:test to define tests, all of those tests will beexecuted within a single application thread, regardless of the value of theconcurrency option oftest().

When process-level test isolation is disabled, each matching test file isimported into the test runner process. Once all test files have been loaded, thetop level tests are executed with a concurrency of one. Because the test filesare all run within the same context, it is possible for tests to interact witheach other in ways that are not possible when isolation is enabled. For example,if a test relies on global state, it is possible for that state to be modifiedby a test originating from another file.

Child process option inheritance#

When running tests in process isolation mode (the default), spawned child processesinherit Node.js options from the parent process, including those specified inconfiguration files. However, certain flags are filtered out to enable propertest runner functionality:

  • --test - Prevented to avoid recursive test execution
  • --experimental-test-coverage - Managed by the test runner
  • --watch - Watch mode is handled at the parent level
  • --experimental-default-config-file - Config file loading is handled by the parent
  • --test-reporter - Reporting is managed by the parent process
  • --test-reporter-destination - Output destinations are controlled by the parent
  • --experimental-config-file - Config file paths are managed by the parent

All other Node.js options from command line arguments, environment variables,and configuration files are inherited by the child processes.

Collecting code coverage#

Stability: 1 - Experimental

When Node.js is started with the--experimental-test-coveragecommand-line flag, code coverage is collected and statistics are reported onceall tests have completed. If theNODE_V8_COVERAGE environment variable isused to specify a code coverage directory, the generated V8 coverage files arewritten to that directory. Node.js core modules and files withinnode_modules/ directories are, by default, not included in the coverage report.However, they can be explicitly included via the--test-coverage-include flag.By default all the matching test files are excluded from the coverage report.Exclusions can be overridden by using the--test-coverage-exclude flag.If coverage is enabled, the coverage report is sent to anytest reporters viathe'test:coverage' event.

Coverage can be disabled on a series of lines using the followingcomment syntax:

/* node:coverage disable */if (anAlwaysFalseCondition) {// Code in this branch will never be executed, but the lines are ignored for// coverage purposes. All lines following the 'disable' comment are ignored// until a corresponding 'enable' comment is encountered.console.log('this is never executed');}/* node:coverage enable */

Coverage can also be disabled for a specified number of lines. After thespecified number of lines, coverage will be automatically reenabled. If thenumber of lines is not explicitly provided, a single line is ignored.

/* node:coverage ignore next */if (anAlwaysFalseCondition) {console.log('this is never executed'); }/* node:coverage ignore next 3 */if (anAlwaysFalseCondition) {console.log('this is never executed');}

Coverage reporters#

The tap and spec reporters will print a summary of the coverage statistics.There is also an lcov reporter that will generate an lcov file which can beused as an in depth coverage report.

node --test --experimental-test-coverage --test-reporter=lcov --test-reporter-destination=lcov.info
  • No test results are reported by this reporter.
  • This reporter should ideally be used alongside another reporter.

Mocking#

Thenode:test module supports mocking during testing via a top-levelmockobject. The following example creates a spy on a function that adds two numberstogether. The spy is then used to assert that the function was called asexpected.

import assertfrom'node:assert';import { mock, test }from'node:test';test('spies on a function',() => {const sum = mock.fn((a, b) => {return a + b;  });  assert.strictEqual(sum.mock.callCount(),0);  assert.strictEqual(sum(3,4),7);  assert.strictEqual(sum.mock.callCount(),1);const call = sum.mock.calls[0];  assert.deepStrictEqual(call.arguments, [3,4]);  assert.strictEqual(call.result,7);  assert.strictEqual(call.error,undefined);// Reset the globally tracked mocks.  mock.reset();});'use strict';const assert =require('node:assert');const { mock, test } =require('node:test');test('spies on a function',() => {const sum = mock.fn((a, b) => {return a + b;  });  assert.strictEqual(sum.mock.callCount(),0);  assert.strictEqual(sum(3,4),7);  assert.strictEqual(sum.mock.callCount(),1);const call = sum.mock.calls[0];  assert.deepStrictEqual(call.arguments, [3,4]);  assert.strictEqual(call.result,7);  assert.strictEqual(call.error,undefined);// Reset the globally tracked mocks.  mock.reset();});

The same mocking functionality is also exposed on theTestContext objectof each test. The following example creates a spy on an object method using theAPI exposed on theTestContext. The benefit of mocking via the test context isthat the test runner will automatically restore all mocked functionality oncethe test finishes.

test('spies on an object method',(t) => {const number = {value:5,add(a) {returnthis.value + a;    },  };  t.mock.method(number,'add');  assert.strictEqual(number.add.mock.callCount(),0);  assert.strictEqual(number.add(3),8);  assert.strictEqual(number.add.mock.callCount(),1);const call = number.add.mock.calls[0];  assert.deepStrictEqual(call.arguments, [3]);  assert.strictEqual(call.result,8);  assert.strictEqual(call.target,undefined);  assert.strictEqual(call.this, number);});

Timers#

Mocking timers is a technique commonly used in software testing to simulate andcontrol the behavior of timers, such assetInterval andsetTimeout,without actually waiting for the specified time intervals.

Refer to theMockTimers class for a full list of methods and features.

This allows developers to write more reliable andpredictable tests for time-dependent functionality.

The example below shows how to mocksetTimeout.Using.enable({ apis: ['setTimeout'] });it will mock thesetTimeout functions in thenode:timers andnode:timers/promises modules,as well as from the Node.js global context.

Note: Destructuring functions such asimport { setTimeout } from 'node:timers'is currently not supported by this API.

import assertfrom'node:assert';import { mock, test }from'node:test';test('mocks setTimeout to be executed synchronously without having to actually wait for it',() => {const fn = mock.fn();// Optionally choose what to mock  mock.timers.enable({apis: ['setTimeout'] });setTimeout(fn,9999);  assert.strictEqual(fn.mock.callCount(),0);// Advance in time  mock.timers.tick(9999);  assert.strictEqual(fn.mock.callCount(),1);// Reset the globally tracked mocks.  mock.timers.reset();// If you call reset mock instance, it will also reset timers instance  mock.reset();});const assert =require('node:assert');const { mock, test } =require('node:test');test('mocks setTimeout to be executed synchronously without having to actually wait for it',() => {const fn = mock.fn();// Optionally choose what to mock  mock.timers.enable({apis: ['setTimeout'] });setTimeout(fn,9999);  assert.strictEqual(fn.mock.callCount(),0);// Advance in time  mock.timers.tick(9999);  assert.strictEqual(fn.mock.callCount(),1);// Reset the globally tracked mocks.  mock.timers.reset();// If you call reset mock instance, it will also reset timers instance  mock.reset();});

The same mocking functionality is also exposed in the mock property on theTestContext objectof each test. The benefit of mocking via the test context isthat the test runner will automatically restore all mocked timersfunctionality once the test finishes.

import assertfrom'node:assert';import { test }from'node:test';test('mocks setTimeout to be executed synchronously without having to actually wait for it',(context) => {const fn = context.mock.fn();// Optionally choose what to mock  context.mock.timers.enable({apis: ['setTimeout'] });setTimeout(fn,9999);  assert.strictEqual(fn.mock.callCount(),0);// Advance in time  context.mock.timers.tick(9999);  assert.strictEqual(fn.mock.callCount(),1);});const assert =require('node:assert');const { test } =require('node:test');test('mocks setTimeout to be executed synchronously without having to actually wait for it',(context) => {const fn = context.mock.fn();// Optionally choose what to mock  context.mock.timers.enable({apis: ['setTimeout'] });setTimeout(fn,9999);  assert.strictEqual(fn.mock.callCount(),0);// Advance in time  context.mock.timers.tick(9999);  assert.strictEqual(fn.mock.callCount(),1);});

Dates#

The mock timers API also allows the mocking of theDate object. This is auseful feature for testing time-dependent functionality, or to simulateinternal calendar functions such asDate.now().

The dates implementation is also part of theMockTimers class. Refer to itfor a full list of methods and features.

Note: Dates and timers are dependent when mocked together. This means thatif you have both theDate andsetTimeout mocked, advancing the time willalso advance the mocked date as they simulate a single internal clock.

The example below show how to mock theDate object and obtain the currentDate.now() value.

import assertfrom'node:assert';import { test }from'node:test';test('mocks the Date object',(context) => {// Optionally choose what to mock  context.mock.timers.enable({apis: ['Date'] });// If not specified, the initial date will be based on 0 in the UNIX epoch  assert.strictEqual(Date.now(),0);// Advance in time will also advance the date  context.mock.timers.tick(9999);  assert.strictEqual(Date.now(),9999);});const assert =require('node:assert');const { test } =require('node:test');test('mocks the Date object',(context) => {// Optionally choose what to mock  context.mock.timers.enable({apis: ['Date'] });// If not specified, the initial date will be based on 0 in the UNIX epoch  assert.strictEqual(Date.now(),0);// Advance in time will also advance the date  context.mock.timers.tick(9999);  assert.strictEqual(Date.now(),9999);});

If there is no initial epoch set, the initial date will be based on 0 in theUnix epoch. This is January 1st, 1970, 00:00:00 UTC. You can set an initial dateby passing anow property to the.enable() method. This value will be usedas the initial date for the mockedDate object. It can either be a positiveinteger, or another Date object.

import assertfrom'node:assert';import { test }from'node:test';test('mocks the Date object with initial time',(context) => {// Optionally choose what to mock  context.mock.timers.enable({apis: ['Date'],now:100 });  assert.strictEqual(Date.now(),100);// Advance in time will also advance the date  context.mock.timers.tick(200);  assert.strictEqual(Date.now(),300);});const assert =require('node:assert');const { test } =require('node:test');test('mocks the Date object with initial time',(context) => {// Optionally choose what to mock  context.mock.timers.enable({apis: ['Date'],now:100 });  assert.strictEqual(Date.now(),100);// Advance in time will also advance the date  context.mock.timers.tick(200);  assert.strictEqual(Date.now(),300);});

You can use the.setTime() method to manually move the mocked date to anothertime. This method only accepts a positive integer.

Note: This method willnot execute any mocked timers that are in the pastfrom the new time.

In the below example we are setting a new time for the mocked date.

import assertfrom'node:assert';import { test }from'node:test';test('sets the time of a date object',(context) => {// Optionally choose what to mock  context.mock.timers.enable({apis: ['Date'],now:100 });  assert.strictEqual(Date.now(),100);// Advance in time will also advance the date  context.mock.timers.setTime(1000);  context.mock.timers.tick(200);  assert.strictEqual(Date.now(),1200);});const assert =require('node:assert');const { test } =require('node:test');test('sets the time of a date object',(context) => {// Optionally choose what to mock  context.mock.timers.enable({apis: ['Date'],now:100 });  assert.strictEqual(Date.now(),100);// Advance in time will also advance the date  context.mock.timers.setTime(1000);  context.mock.timers.tick(200);  assert.strictEqual(Date.now(),1200);});

Timers scheduled in the past willnot run when you callsetTime(). To execute those timers, you can usethe.tick() method to move forward from the new time.

import assertfrom'node:assert';import { test }from'node:test';test('setTime does not execute timers',(context) => {// Optionally choose what to mock  context.mock.timers.enable({apis: ['setTimeout','Date'] });const fn = context.mock.fn();setTimeout(fn,1000);  context.mock.timers.setTime(800);// Timer is not executed as the time is not yet reached  assert.strictEqual(fn.mock.callCount(),0);  assert.strictEqual(Date.now(),800);  context.mock.timers.setTime(1200);// Timer is still not executed  assert.strictEqual(fn.mock.callCount(),0);// Advance in time to execute the timer  context.mock.timers.tick(0);  assert.strictEqual(fn.mock.callCount(),1);  assert.strictEqual(Date.now(),1200);});const assert =require('node:assert');const { test } =require('node:test');test('runs timers as setTime passes ticks',(context) => {// Optionally choose what to mock  context.mock.timers.enable({apis: ['setTimeout','Date'] });const fn = context.mock.fn();setTimeout(fn,1000);  context.mock.timers.setTime(800);// Timer is not executed as the time is not yet reached  assert.strictEqual(fn.mock.callCount(),0);  assert.strictEqual(Date.now(),800);  context.mock.timers.setTime(1200);// Timer is executed as the time is now reached  assert.strictEqual(fn.mock.callCount(),1);  assert.strictEqual(Date.now(),1200);});

Using.runAll() will execute all timers that are currently in the queue. Thiswill also advance the mocked date to the time of the last timer that wasexecuted as if the time has passed.

import assertfrom'node:assert';import { test }from'node:test';test('runs timers as setTime passes ticks',(context) => {// Optionally choose what to mock  context.mock.timers.enable({apis: ['setTimeout','Date'] });const fn = context.mock.fn();setTimeout(fn,1000);setTimeout(fn,2000);setTimeout(fn,3000);  context.mock.timers.runAll();// All timers are executed as the time is now reached  assert.strictEqual(fn.mock.callCount(),3);  assert.strictEqual(Date.now(),3000);});const assert =require('node:assert');const { test } =require('node:test');test('runs timers as setTime passes ticks',(context) => {// Optionally choose what to mock  context.mock.timers.enable({apis: ['setTimeout','Date'] });const fn = context.mock.fn();setTimeout(fn,1000);setTimeout(fn,2000);setTimeout(fn,3000);  context.mock.timers.runAll();// All timers are executed as the time is now reached  assert.strictEqual(fn.mock.callCount(),3);  assert.strictEqual(Date.now(),3000);});

Snapshot testing#

History
VersionChanges
v23.4.0

Snapshot testing is no longer experimental.

v22.3.0

Added in: v22.3.0

Snapshot tests allow arbitrary values to be serialized into string values andcompared against a set of known good values. The known good values are known assnapshots, and are stored in a snapshot file. Snapshot files are managed by thetest runner, but are designed to be human readable to aid in debugging. Bestpractice is for snapshot files to be checked into source control along with yourtest files.

Snapshot files are generated by starting Node.js with the--test-update-snapshots command-line flag. A separate snapshot file isgenerated for each test file. By default, the snapshot file has the same nameas the test file with a.snapshot file extension. This behavior can beconfigured using thesnapshot.setResolveSnapshotPath() function. Eachsnapshot assertion corresponds to an export in the snapshot file.

An example snapshot test is shown below. The first time this test is executed,it will fail because the corresponding snapshot file does not exist.

// test.jssuite('suite of snapshot tests',() => {test('snapshot test',(t) => {    t.assert.snapshot({value1:1,value2:2 });    t.assert.snapshot(5);  });});

Generate the snapshot file by running the test file with--test-update-snapshots. The test should pass, and a file namedtest.js.snapshot is created in the same directory as the test file. Thecontents of the snapshot file are shown below. Each snapshot is identified bythe full name of test and a counter to differentiate between snapshots in thesame test.

exports[`suite of snapshot tests > snapshot test 1`] =`{  "value1": 1,  "value2": 2}`;exports[`suite of snapshot tests > snapshot test 2`] =`5`;

Once the snapshot file is created, run the tests again without the--test-update-snapshots flag. The tests should pass now.

Test reporters#

History
VersionChanges
v23.0.0

The default reporter on non-TTY stdout is changed fromtap tospec, aligning with TTY stdout.

v19.9.0, v18.17.0

Reporters are now exposed atnode:test/reporters.

v19.6.0, v18.15.0

Added in: v19.6.0, v18.15.0

Thenode:test module supports passing--test-reporterflags for the test runner to use a specific reporter.

The following built-reporters are supported:

  • specThespec reporter outputs the test results in a human-readable format. Thisis the default reporter.

  • tapThetap reporter outputs the test results in theTAP format.

  • dotThedot reporter outputs the test results in a compact format,where each passing test is represented by a.,and each failing test is represented by aX.

  • junitThe junit reporter outputs test results in a jUnit XML format

  • lcovThelcov reporter outputs test coverage when used with the--experimental-test-coverage flag.

The exact output of these reporters is subject to change between versions ofNode.js, and should not be relied on programmatically. If programmatic accessto the test runner's output is required, use the events emitted by the<TestsStream>.

The reporters are available via thenode:test/reporters module:

import { tap, spec, dot, junit, lcov }from'node:test/reporters';const { tap, spec, dot, junit, lcov } =require('node:test/reporters');

Custom reporters#

--test-reporter can be used to specify a path to custom reporter.A custom reporter is a module that exports a valueaccepted bystream.compose.Reporters should transform events emitted by a<TestsStream>

Example of a custom reporter using<stream.Transform>:

import {Transform }from'node:stream';const customReporter =newTransform({writableObjectMode:true,transform(event, encoding, callback) {switch (event.type) {case'test:dequeue':callback(null,`test${event.data.name} dequeued`);break;case'test:enqueue':callback(null,`test${event.data.name} enqueued`);break;case'test:watch:drained':callback(null,'test watch queue drained');break;case'test:watch:restarted':callback(null,'test watch restarted due to file change');break;case'test:start':callback(null,`test${event.data.name} started`);break;case'test:pass':callback(null,`test${event.data.name} passed`);break;case'test:fail':callback(null,`test${event.data.name} failed`);break;case'test:plan':callback(null,'test plan');break;case'test:diagnostic':case'test:stderr':case'test:stdout':callback(null, event.data.message);break;case'test:coverage': {const { totalLineCount } = event.data.summary.totals;callback(null,`total line count:${totalLineCount}\n`);break;      }    }  },});exportdefault customReporter;const {Transform } =require('node:stream');const customReporter =newTransform({writableObjectMode:true,transform(event, encoding, callback) {switch (event.type) {case'test:dequeue':callback(null,`test${event.data.name} dequeued`);break;case'test:enqueue':callback(null,`test${event.data.name} enqueued`);break;case'test:watch:drained':callback(null,'test watch queue drained');break;case'test:watch:restarted':callback(null,'test watch restarted due to file change');break;case'test:start':callback(null,`test${event.data.name} started`);break;case'test:pass':callback(null,`test${event.data.name} passed`);break;case'test:fail':callback(null,`test${event.data.name} failed`);break;case'test:plan':callback(null,'test plan');break;case'test:diagnostic':case'test:stderr':case'test:stdout':callback(null, event.data.message);break;case'test:coverage': {const { totalLineCount } = event.data.summary.totals;callback(null,`total line count:${totalLineCount}\n`);break;      }    }  },});module.exports = customReporter;

Example of a custom reporter using a generator function:

exportdefaultasyncfunction *customReporter(source) {forawait (const eventof source) {switch (event.type) {case'test:dequeue':yield`test${event.data.name} dequeued\n`;break;case'test:enqueue':yield`test${event.data.name} enqueued\n`;break;case'test:watch:drained':yield'test watch queue drained\n';break;case'test:watch:restarted':yield'test watch restarted due to file change\n';break;case'test:start':yield`test${event.data.name} started\n`;break;case'test:pass':yield`test${event.data.name} passed\n`;break;case'test:fail':yield`test${event.data.name} failed\n`;break;case'test:plan':yield'test plan\n';break;case'test:diagnostic':case'test:stderr':case'test:stdout':yield`${event.data.message}\n`;break;case'test:coverage': {const { totalLineCount } = event.data.summary.totals;yield`total line count:${totalLineCount}\n`;break;      }    }  }}module.exports =asyncfunction *customReporter(source) {forawait (const eventof source) {switch (event.type) {case'test:dequeue':yield`test${event.data.name} dequeued\n`;break;case'test:enqueue':yield`test${event.data.name} enqueued\n`;break;case'test:watch:drained':yield'test watch queue drained\n';break;case'test:watch:restarted':yield'test watch restarted due to file change\n';break;case'test:start':yield`test${event.data.name} started\n`;break;case'test:pass':yield`test${event.data.name} passed\n`;break;case'test:fail':yield`test${event.data.name} failed\n`;break;case'test:plan':yield'test plan\n';break;case'test:diagnostic':case'test:stderr':case'test:stdout':yield`${event.data.message}\n`;break;case'test:coverage': {const { totalLineCount } = event.data.summary.totals;yield`total line count:${totalLineCount}\n`;break;      }    }  }};

The value provided to--test-reporter should be a string like one used in animport() in JavaScript code, or a value provided for--import.

Multiple reporters#

The--test-reporter flag can be specified multiple times to report testresults in several formats. In this situationit is required to specify a destination for each reporterusing--test-reporter-destination.Destination can bestdout,stderr, or a file path.Reporters and destinations are paired accordingto the order they were specified.

In the following example, thespec reporter will output tostdout,and thedot reporter will output tofile.txt:

node --test-reporter=spec --test-reporter=dot --test-reporter-destination=stdout --test-reporter-destination=file.txt

When a single reporter is specified, the destination will default tostdout,unless a destination is explicitly provided.

run([options])#

History
VersionChanges
v25.6.0

Add theenv option.

v24.7.0

Added a rerunFailuresFilePath option.

v23.0.0

Added thecwd option.

v23.0.0, v22.10.0

Added coverage options.

v22.8.0

Added theisolation option.

v22.6.0

Added theglobPatterns option.

v22.0.0, v20.14.0

Added theforceExit option.

v20.1.0, v18.17.0

Add a testNamePatterns option.

v18.9.0, v16.19.0

Added in: v18.9.0, v16.19.0

  • options<Object> Configuration options for running tests. The followingproperties are supported:
    • concurrency<number> |<boolean> If a number is provided,then that many test processes would run in parallel, where each processcorresponds to one test file.Iftrue, it would runos.availableParallelism() - 1 test files inparallel.Iffalse, it would only run one test file at a time.Default:false.
    • cwd<string> Specifies the current working directory to be used by the test runner.Serves as the base path for resolving files as ifrunning tests from the command line from that directory.Default:process.cwd().
    • files<Array> An array containing the list of files to run.Default: Same asrunning tests from the command line.
    • forceExit<boolean> Configures the test runner to exit the process onceall known tests have finished executing even if the event loop wouldotherwise remain active.Default:false.
    • globPatterns<Array> An array containing the list of glob patterns tomatch test files. This option cannot be used together withfiles.Default: Same asrunning tests from the command line.
    • inspectPort<number> |<Function> Sets inspector port of test child process.This can be a number, or a function that takes no arguments and returns anumber. If a nullish value is provided, each process gets its own port,incremented from the primary'sprocess.debugPort. This option is ignoredif theisolation option is set to'none' as no child processes arespawned.Default:undefined.
    • isolation<string> Configures the type of test isolation. If set to'process', each test file is run in a separate child process. If set to'none', all test files run in the current process.Default:'process'.
    • only<boolean> If truthy, the test context will only run tests thathave theonly option set
    • setup<Function> A function that accepts theTestsStream instanceand can be used to setup listeners before any tests are run.Default:undefined.
    • execArgv<Array> An array of CLI flags to pass to thenode executable whenspawning the subprocesses. This option has no effect whenisolation is'none'.Default:[]
    • argv<Array> An array of CLI flags to pass to each test file when spawning thesubprocesses. This option has no effect whenisolation is'none'.Default:[].
    • signal<AbortSignal> Allows aborting an in-progress test execution.
    • testNamePatterns<string> |<RegExp> |<Array> A String, RegExp or a RegExp Array,that can be used to only run tests whose name matches the provided pattern.Test name patterns are interpreted as JavaScript regular expressions.For each test that is executed, any corresponding test hooks, such asbeforeEach(), are also run.Default:undefined.
    • testSkipPatterns<string> |<RegExp> |<Array> A String, RegExp or a RegExp Array,that can be used to exclude running tests whose name matches the provided pattern.Test name patterns are interpreted as JavaScript regular expressions.For each test that is executed, any corresponding test hooks, such asbeforeEach(), are also run.Default:undefined.
    • timeout<number> A number of milliseconds the test execution willfail after.If unspecified, subtests inherit this value from their parent.Default:Infinity.
    • watch<boolean> Whether to run in watch mode or not.Default:false.
    • shard<Object> Running tests in a specific shard.Default:undefined.
      • index<number> is a positive integer between 1 and<total>that specifies the index of the shard to run. This option isrequired.
      • total<number> is a positive integer that specifies the total numberof shards to split the test files to. This option isrequired.
    • rerunFailuresFilePath<string> A file path where the test runner willstore the state of the tests to allow rerunning only the failed tests on a next run.see [Rerunning failed tests][] for more information.Default:undefined.
    • coverage<boolean> enablecode coverage collection.Default:false.
    • coverageExcludeGlobs<string> |<Array> Excludes specific files from code coverageusing a glob pattern, which can match both absolute and relative file paths.This property is only applicable whencoverage was set totrue.If bothcoverageExcludeGlobs andcoverageIncludeGlobs are provided,files must meetboth criteria to be included in the coverage report.Default:undefined.
    • coverageIncludeGlobs<string> |<Array> Includes specific files in code coverageusing a glob pattern, which can match both absolute and relative file paths.This property is only applicable whencoverage was set totrue.If bothcoverageExcludeGlobs andcoverageIncludeGlobs are provided,files must meetboth criteria to be included in the coverage report.Default:undefined.
    • lineCoverage<number> Require a minimum percent of covered lines. If codecoverage does not reach the threshold specified, the process will exit with code1.Default:0.
    • branchCoverage<number> Require a minimum percent of covered branches. If codecoverage does not reach the threshold specified, the process will exit with code1.Default:0.
    • functionCoverage<number> Require a minimum percent of covered functions. If codecoverage does not reach the threshold specified, the process will exit with code1.Default:0.
    • env<Object> Specify environment variables to be passed along to the test process.This options is not compatible withisolation='none'. These variables will overridethose from the main process, and are not merged withprocess.env.Default:process.env.
  • Returns:<TestsStream>

Note:shard is used to horizontally parallelize test running acrossmachines or processes, ideal for large-scale executions across variedenvironments. It's incompatible withwatch mode, tailored for rapidcode iteration by automatically rerunning tests on file changes.

import { tap }from'node:test/reporters';import { run }from'node:test';import processfrom'node:process';import pathfrom'node:path';run({files: [path.resolve('./tests/test.js')] }) .on('test:fail',() => {   process.exitCode =1; }) .compose(tap) .pipe(process.stdout);const { tap } =require('node:test/reporters');const { run } =require('node:test');const path =require('node:path');run({files: [path.resolve('./tests/test.js')] }) .on('test:fail',() => {   process.exitCode =1; }) .compose(tap) .pipe(process.stdout);

suite([name][, options][, fn])#

Added in: v22.0.0, v20.13.0
  • name<string> The name of the suite, which is displayed when reporting testresults.Default: Thename property offn, or'<anonymous>' iffndoes not have a name.
  • options<Object> Optional configuration options for the suite.This supports the same options astest([name][, options][, fn]).
  • fn<Function> |<AsyncFunction> The suite function declaring nested tests andsuites. The first argument to this function is aSuiteContext object.Default: A no-op function.
  • Returns:<Promise> Immediately fulfilled withundefined.

Thesuite() function is imported from thenode:test module.

suite.skip([name][, options][, fn])#

Added in: v22.0.0, v20.13.0

Shorthand for skipping a suite. This is the same assuite([name], { skip: true }[, fn]).

suite.todo([name][, options][, fn])#

Added in: v22.0.0, v20.13.0

Shorthand for marking a suite asTODO. This is the same assuite([name], { todo: true }[, fn]).

suite.only([name][, options][, fn])#

Added in: v22.0.0, v20.13.0

Shorthand for marking a suite asonly. This is the same assuite([name], { only: true }[, fn]).

test([name][, options][, fn])#

History
VersionChanges
v20.2.0, v18.17.0

Added theskip,todo, andonly shorthands.

v18.8.0, v16.18.0

Add asignal option.

v18.7.0, v16.17.0

Add atimeout option.

v18.0.0, v16.17.0

Added in: v18.0.0, v16.17.0

  • name<string> The name of the test, which is displayed when reporting testresults.Default: Thename property offn, or'<anonymous>' iffndoes not have a name.
  • options<Object> Configuration options for the test. The followingproperties are supported:
    • concurrency<number> |<boolean> If a number is provided,then that many tests would run asynchronously (they are still managed by the single-threaded event loop).Iftrue, all scheduled asynchronous tests run concurrently within thethread. Iffalse, only one test runs at a time.If unspecified, subtests inherit this value from their parent.Default:false.
    • only<boolean> If truthy, and the test context is configured to runonly tests, then this test will be run. Otherwise, the test is skipped.Default:false.
    • signal<AbortSignal> Allows aborting an in-progress test.
    • skip<boolean> |<string> If truthy, the test is skipped. If a string isprovided, that string is displayed in the test results as the reason forskipping the test.Default:false.
    • todo<boolean> |<string> If truthy, the test marked asTODO. If a stringis provided, that string is displayed in the test results as the reason whythe test isTODO.Default:false.
    • timeout<number> A number of milliseconds the test will fail after.If unspecified, subtests inherit this value from their parent.Default:Infinity.
    • plan<number> The number of assertions and subtests expected to be run in the test.If the number of assertions run in the test does not match the numberspecified in the plan, the test will fail.Default:undefined.
  • fn<Function> |<AsyncFunction> The function under test. The first argumentto this function is aTestContext object. If the test uses callbacks,the callback function is passed as the second argument.Default: A no-opfunction.
  • Returns:<Promise> Fulfilled withundefined oncethe test completes, or immediately if the test runs within a suite.

Thetest() function is the value imported from thetest module. Eachinvocation of this function results in reporting the test to the<TestsStream>.

TheTestContext object passed to thefn argument can be used to performactions related to the current test. Examples include skipping the test, addingadditional diagnostic information, or creating subtests.

test() returns aPromise that fulfills once the test completes.iftest() is called within a suite, it fulfills immediately.The return value can usually be discarded for top level tests.However, the return value from subtests should be used to prevent the parenttest from finishing first and cancelling the subtestas shown in the following example.

test('top level test',async (t) => {// The setTimeout() in the following subtest would cause it to outlive its// parent test if 'await' is removed on the next line. Once the parent test// completes, it will cancel any outstanding subtests.await t.test('longer running subtest',async (t) => {returnnewPromise((resolve, reject) => {setTimeout(resolve,1000);    });  });});

Thetimeout option can be used to fail the test if it takes longer thantimeout milliseconds to complete. However, it is not a reliable mechanism forcanceling tests because a running test might block the application thread andthus prevent the scheduled cancellation.

test.skip([name][, options][, fn])#

Shorthand for skipping a test,same astest([name], { skip: true }[, fn]).

test.todo([name][, options][, fn])#

Shorthand for marking a test asTODO,same astest([name], { todo: true }[, fn]).

test.only([name][, options][, fn])#

Shorthand for marking a test asonly,same astest([name], { only: true }[, fn]).

describe([name][, options][, fn])#

Alias forsuite().

Thedescribe() function is imported from thenode:test module.

describe.skip([name][, options][, fn])#

Shorthand for skipping a suite. This is the same asdescribe([name], { skip: true }[, fn]).

describe.todo([name][, options][, fn])#

Shorthand for marking a suite asTODO. This is the same asdescribe([name], { todo: true }[, fn]).

describe.only([name][, options][, fn])#

Added in: v19.8.0, v18.15.0

Shorthand for marking a suite asonly. This is the same asdescribe([name], { only: true }[, fn]).

it([name][, options][, fn])#

History
VersionChanges
v19.8.0, v18.16.0

Callingit() is now equivalent to callingtest().

v18.6.0, v16.17.0

Added in: v18.6.0, v16.17.0

Alias fortest().

Theit() function is imported from thenode:test module.

it.skip([name][, options][, fn])#

Shorthand for skipping a test,same asit([name], { skip: true }[, fn]).

it.todo([name][, options][, fn])#

Shorthand for marking a test asTODO,same asit([name], { todo: true }[, fn]).

it.only([name][, options][, fn])#

Added in: v19.8.0, v18.15.0

Shorthand for marking a test asonly,same asit([name], { only: true }[, fn]).

before([fn][, options])#

Added in: v18.8.0, v16.18.0
  • fn<Function> |<AsyncFunction> The hook function.If the hook uses callbacks,the callback function is passed as the second argument.Default: A no-opfunction.
  • options<Object> Configuration options for the hook. The followingproperties are supported:
    • signal<AbortSignal> Allows aborting an in-progress hook.
    • timeout<number> A number of milliseconds the hook will fail after.If unspecified, subtests inherit this value from their parent.Default:Infinity.

This function creates a hook that runs before executing a suite.

describe('tests',async () => {before(() =>console.log('about to run some test'));it('is a subtest',() => {// Some relevant assertions here  });});

after([fn][, options])#

Added in: v18.8.0, v16.18.0
  • fn<Function> |<AsyncFunction> The hook function.If the hook uses callbacks,the callback function is passed as the second argument.Default: A no-opfunction.
  • options<Object> Configuration options for the hook. The followingproperties are supported:
    • signal<AbortSignal> Allows aborting an in-progress hook.
    • timeout<number> A number of milliseconds the hook will fail after.If unspecified, subtests inherit this value from their parent.Default:Infinity.

This function creates a hook that runs after executing a suite.

describe('tests',async () => {after(() =>console.log('finished running tests'));it('is a subtest',() => {// Some relevant assertion here  });});

Note: Theafter hook is guaranteed to run,even if tests within the suite fail.

beforeEach([fn][, options])#

Added in: v18.8.0, v16.18.0
  • fn<Function> |<AsyncFunction> The hook function.If the hook uses callbacks,the callback function is passed as the second argument.Default: A no-opfunction.
  • options<Object> Configuration options for the hook. The followingproperties are supported:
    • signal<AbortSignal> Allows aborting an in-progress hook.
    • timeout<number> A number of milliseconds the hook will fail after.If unspecified, subtests inherit this value from their parent.Default:Infinity.

This function creates a hook that runs before each test in the current suite.

describe('tests',async () => {beforeEach(() =>console.log('about to run a test'));it('is a subtest',() => {// Some relevant assertion here  });});

afterEach([fn][, options])#

Added in: v18.8.0, v16.18.0
  • fn<Function> |<AsyncFunction> The hook function.If the hook uses callbacks,the callback function is passed as the second argument.Default: A no-opfunction.
  • options<Object> Configuration options for the hook. The followingproperties are supported:
    • signal<AbortSignal> Allows aborting an in-progress hook.
    • timeout<number> A number of milliseconds the hook will fail after.If unspecified, subtests inherit this value from their parent.Default:Infinity.

This function creates a hook that runs after each test in the current suite.TheafterEach() hook is run even if the test fails.

describe('tests',async () => {afterEach(() =>console.log('finished running a test'));it('is a subtest',() => {// Some relevant assertion here  });});

assert#

Added in: v23.7.0, v22.14.0

An object whose methods are used to configure available assertions on theTestContext objects in the current process. The methods fromnode:assertand snapshot testing functions are available by default.

It is possible to apply the same configuration to all files by placing commonconfiguration code in a modulepreloaded with--require or--import.

assert.register(name, fn)#

Added in: v23.7.0, v22.14.0

Defines a new assertion function with the provided name and function. If anassertion already exists with the same name, it is overwritten.

snapshot#

Added in: v22.3.0

An object whose methods are used to configure default snapshot settings in thecurrent process. It is possible to apply the same configuration to all files byplacing common configuration code in a module preloaded with--require or--import.

snapshot.setDefaultSnapshotSerializers(serializers)#

Added in: v22.3.0
  • serializers<Array> An array of synchronous functions used as the defaultserializers for snapshot tests.

This function is used to customize the default serialization mechanism used bythe test runner. By default, the test runner performs serialization by callingJSON.stringify(value, null, 2) on the provided value.JSON.stringify() doeshave limitations regarding circular structures and supported data types. If amore robust serialization mechanism is required, this function should be used.

snapshot.setResolveSnapshotPath(fn)#

Added in: v22.3.0
  • fn<Function> A function used to compute the location of the snapshot file.The function receives the path of the test file as its only argument. If thetest is not associated with a file (for example in the REPL), the input isundefined.fn() must return a string specifying the location of the snapshotsnapshot file.

This function is used to customize the location of the snapshot file used forsnapshot testing. By default, the snapshot filename is the same as the entrypoint filename with a.snapshot file extension.

Class:MockFunctionContext#

Added in: v19.1.0, v18.13.0

TheMockFunctionContext class is used to inspect or manipulate the behavior ofmocks created via theMockTracker APIs.

ctx.calls#

Added in: v19.1.0, v18.13.0

A getter that returns a copy of the internal array used to track calls to themock. Each entry in the array is an object with the following properties.

  • arguments<Array> An array of the arguments passed to the mock function.
  • error<any> If the mocked function threw then this property contains thethrown value.Default:undefined.
  • result<any> The value returned by the mocked function.
  • stack<Error> AnError object whose stack can be used to determine thecallsite of the mocked function invocation.
  • target<Function> |<undefined> If the mocked function is a constructor, thisfield contains the class being constructed. Otherwise this will beundefined.
  • this<any> The mocked function'sthis value.

ctx.callCount()#

Added in: v19.1.0, v18.13.0
  • Returns:<integer> The number of times that this mock has been invoked.

This function returns the number of times that this mock has been invoked. Thisfunction is more efficient than checkingctx.calls.length becausectx.callsis a getter that creates a copy of the internal call tracking array.

ctx.mockImplementation(implementation)#

Added in: v19.1.0, v18.13.0

This function is used to change the behavior of an existing mock.

The following example creates a mock function usingt.mock.fn(), calls themock function, and then changes the mock implementation to a different function.

test('changes a mock behavior',(t) => {let cnt =0;functionaddOne() {    cnt++;return cnt;  }functionaddTwo() {    cnt +=2;return cnt;  }const fn = t.mock.fn(addOne);  assert.strictEqual(fn(),1);  fn.mock.mockImplementation(addTwo);  assert.strictEqual(fn(),3);  assert.strictEqual(fn(),5);});

ctx.mockImplementationOnce(implementation[, onCall])#

Added in: v19.1.0, v18.13.0
  • implementation<Function> |<AsyncFunction> The function to be used as themock's implementation for the invocation number specified byonCall.
  • onCall<integer> The invocation number that will useimplementation. Ifthe specified invocation has already occurred then an exception is thrown.Default: The number of the next invocation.

This function is used to change the behavior of an existing mock for a singleinvocation. Once invocationonCall has occurred, the mock will revert towhatever behavior it would have used hadmockImplementationOnce() not beencalled.

The following example creates a mock function usingt.mock.fn(), calls themock function, changes the mock implementation to a different function for thenext invocation, and then resumes its previous behavior.

test('changes a mock behavior once',(t) => {let cnt =0;functionaddOne() {    cnt++;return cnt;  }functionaddTwo() {    cnt +=2;return cnt;  }const fn = t.mock.fn(addOne);  assert.strictEqual(fn(),1);  fn.mock.mockImplementationOnce(addTwo);  assert.strictEqual(fn(),3);  assert.strictEqual(fn(),4);});

ctx.resetCalls()#

Added in: v19.3.0, v18.13.0

Resets the call history of the mock function.

ctx.restore()#

Added in: v19.1.0, v18.13.0

Resets the implementation of the mock function to its original behavior. Themock can still be used after calling this function.

Class:MockModuleContext#

Added in: v22.3.0, v20.18.0

Stability: 1.0 - Early development

TheMockModuleContext class is used to manipulate the behavior of module mockscreated via theMockTracker APIs.

ctx.restore()#

Added in: v22.3.0, v20.18.0

Resets the implementation of the mock module.

Class:MockPropertyContext#

Added in: v24.3.0, v22.20.0

TheMockPropertyContext class is used to inspect or manipulate the behaviorof property mocks created via theMockTracker APIs.

ctx.accesses#

A getter that returns a copy of the internal array used to track accesses (get/set) tothe mocked property. Each entry in the array is an object with the following properties:

  • type<string> Either'get' or'set', indicating the type of access.
  • value<any> The value that was read (for'get') or written (for'set').
  • stack<Error> AnError object whose stack can be used to determine thecallsite of the mocked function invocation.

ctx.accessCount()#

  • Returns:<integer> The number of times that the property was accessed (read or written).

This function returns the number of times that the property was accessed.This function is more efficient than checkingctx.accesses.length becausectx.accesses is a getter that creates a copy of the internal access tracking array.

ctx.mockImplementation(value)#

  • value<any> The new value to be set as the mocked property value.

This function is used to change the value returned by the mocked property getter.

ctx.mockImplementationOnce(value[, onAccess])#

  • value<any> The value to be used as the mock'simplementation for the invocation number specified byonAccess.
  • onAccess<integer> The invocation number that will usevalue. Ifthe specified invocation has already occurred then an exception is thrown.Default: The number of the next invocation.

This function is used to change the behavior of an existing mock for a singleinvocation. Once invocationonAccess has occurred, the mock will revert towhatever behavior it would have used hadmockImplementationOnce() not beencalled.

The following example creates a mock function usingt.mock.property(), calls themock property, changes the mock implementation to a different value for thenext invocation, and then resumes its previous behavior.

test('changes a mock behavior once',(t) => {const obj = {foo:1 };const prop = t.mock.property(obj,'foo',5);  assert.strictEqual(obj.foo,5);  prop.mock.mockImplementationOnce(25);  assert.strictEqual(obj.foo,25);  assert.strictEqual(obj.foo,5);});
Caveat#

For consistency with the rest of the mocking API, this function treats both property gets and setsas accesses. If a property set occurs at the same access index, the "once" value will be consumedby the set operation, and the mocked property value will be changed to the "once" value. This maylead to unexpected behavior if you intend the "once" value to only be used for a get operation.

ctx.resetAccesses()#

Resets the access history of the mocked property.

ctx.restore()#

Resets the implementation of the mock property to its original behavior. Themock can still be used after calling this function.

Class:MockTracker#

Added in: v19.1.0, v18.13.0

TheMockTracker class is used to manage mocking functionality. The test runnermodule provides a top levelmock export which is aMockTracker instance.Each test also provides its ownMockTracker instance via the test context'smock property.

mock.fn([original[, implementation]][, options])#

Added in: v19.1.0, v18.13.0
  • original<Function> |<AsyncFunction> An optional function to create a mock on.Default: A no-op function.
  • implementation<Function> |<AsyncFunction> An optional function used as themock implementation fororiginal. This is useful for creating mocks thatexhibit one behavior for a specified number of calls and then restore thebehavior oforiginal.Default: The function specified byoriginal.
  • options<Object> Optional configuration options for the mock function. Thefollowing properties are supported:
    • times<integer> The number of times that the mock will use the behavior ofimplementation. Once the mock function has been calledtimes times, itwill automatically restore the behavior oforiginal. This value must be aninteger greater than zero.Default:Infinity.
  • Returns:<Proxy> The mocked function. The mocked function contains a specialmock property, which is an instance ofMockFunctionContext, and canbe used for inspecting and changing the behavior of the mocked function.

This function is used to create a mock function.

The following example creates a mock function that increments a counter by oneon each invocation. Thetimes option is used to modify the mock behavior suchthat the first two invocations add two to the counter instead of one.

test('mocks a counting function',(t) => {let cnt =0;functionaddOne() {    cnt++;return cnt;  }functionaddTwo() {    cnt +=2;return cnt;  }const fn = t.mock.fn(addOne, addTwo, {times:2 });  assert.strictEqual(fn(),2);  assert.strictEqual(fn(),4);  assert.strictEqual(fn(),5);  assert.strictEqual(fn(),6);});

mock.getter(object, methodName[, implementation][, options])#

Added in: v19.3.0, v18.13.0

This function is syntax sugar forMockTracker.method withoptions.getterset totrue.

mock.method(object, methodName[, implementation][, options])#

Added in: v19.1.0, v18.13.0
  • object<Object> The object whose method is being mocked.
  • methodName<string> |<symbol> The identifier of the method onobject to mock.Ifobject[methodName] is not a function, an error is thrown.
  • implementation<Function> |<AsyncFunction> An optional function used as themock implementation forobject[methodName].Default: The original methodspecified byobject[methodName].
  • options<Object> Optional configuration options for the mock method. Thefollowing properties are supported:
    • getter<boolean> Iftrue,object[methodName] is treated as a getter.This option cannot be used with thesetter option.Default: false.
    • setter<boolean> Iftrue,object[methodName] is treated as a setter.This option cannot be used with thegetter option.Default: false.
    • times<integer> The number of times that the mock will use the behavior ofimplementation. Once the mocked method has been calledtimes times, itwill automatically restore the original behavior. This value must be aninteger greater than zero.Default:Infinity.
  • Returns:<Proxy> The mocked method. The mocked method contains a specialmock property, which is an instance ofMockFunctionContext, and canbe used for inspecting and changing the behavior of the mocked method.

This function is used to create a mock on an existing object method. Thefollowing example demonstrates how a mock is created on an existing objectmethod.

test('spies on an object method',(t) => {const number = {value:5,subtract(a) {returnthis.value - a;    },  };  t.mock.method(number,'subtract');  assert.strictEqual(number.subtract.mock.callCount(),0);  assert.strictEqual(number.subtract(3),2);  assert.strictEqual(number.subtract.mock.callCount(),1);const call = number.subtract.mock.calls[0];  assert.deepStrictEqual(call.arguments, [3]);  assert.strictEqual(call.result,2);  assert.strictEqual(call.error,undefined);  assert.strictEqual(call.target,undefined);  assert.strictEqual(call.this, number);});

mock.module(specifier[, options])#

History
VersionChanges
v24.0.0, v22.17.0

Support JSON modules.

v22.3.0, v20.18.0

Added in: v22.3.0, v20.18.0

Stability: 1.0 - Early development

  • specifier<string> |<URL> A string identifying the module to mock.
  • options<Object> Optional configuration options for the mock module. Thefollowing properties are supported:
    • cache<boolean> Iffalse, each call torequire() orimport()generates a new mock module. Iftrue, subsequent calls will return the samemodule mock, and the mock module is inserted into the CommonJS cache.Default: false.
    • defaultExport<any> An optional value used as the mocked module's defaultexport. If this value is not provided, ESM mocks do not include a defaultexport. If the mock is a CommonJS or builtin module, this setting is used asthe value ofmodule.exports. If this value is not provided, CJS and builtinmocks use an empty object as the value ofmodule.exports.
    • namedExports<Object> An optional object whose keys and values are used tocreate the named exports of the mock module. If the mock is a CommonJS orbuiltin module, these values are copied ontomodule.exports. Therefore, if amock is created with both named exports and a non-object default export, themock will throw an exception when used as a CJS or builtin module.
  • Returns:<MockModuleContext> An object that can be used to manipulate the mock.

This function is used to mock the exports of ECMAScript modules, CommonJS modules, JSON modules, andNode.js builtin modules. Any references to the original module prior to mocking are not impacted. Inorder to enable module mocking, Node.js must be started with the--experimental-test-module-mocks command-line flag.

The following example demonstrates how a mock is created for a module.

test('mocks a builtin module in both module systems',async (t) => {// Create a mock of 'node:readline' with a named export named 'fn', which// does not exist in the original 'node:readline' module.const mock = t.mock.module('node:readline', {namedExports: {fn() {return42; } },  });let esmImpl =awaitimport('node:readline');let cjsImpl =require('node:readline');// cursorTo() is an export of the original 'node:readline' module.  assert.strictEqual(esmImpl.cursorTo,undefined);  assert.strictEqual(cjsImpl.cursorTo,undefined);  assert.strictEqual(esmImpl.fn(),42);  assert.strictEqual(cjsImpl.fn(),42);  mock.restore();// The mock is restored, so the original builtin module is returned.  esmImpl =awaitimport('node:readline');  cjsImpl =require('node:readline');  assert.strictEqual(typeof esmImpl.cursorTo,'function');  assert.strictEqual(typeof cjsImpl.cursorTo,'function');  assert.strictEqual(esmImpl.fn,undefined);  assert.strictEqual(cjsImpl.fn,undefined);});

mock.property(object, propertyName[, value])#

Added in: v24.3.0, v22.20.0
  • object<Object> The object whose value is being mocked.
  • propertyName<string> |<symbol> The identifier of the property onobject to mock.
  • value<any> An optional value used as the mock valueforobject[propertyName].Default: The original property value.
  • Returns:<Proxy> A proxy to the mocked object. The mocked object contains aspecialmock property, which is an instance ofMockPropertyContext, andcan be used for inspecting and changing the behavior of the mocked property.

Creates a mock for a property value on an object. This allows you to track and control access to a specific property,including how many times it is read (getter) or written (setter), and to restore the original value after mocking.

test('mocks a property value',(t) => {const obj = {foo:42 };const prop = t.mock.property(obj,'foo',100);  assert.strictEqual(obj.foo,100);  assert.strictEqual(prop.mock.accessCount(),1);  assert.strictEqual(prop.mock.accesses[0].type,'get');  assert.strictEqual(prop.mock.accesses[0].value,100);  obj.foo =200;  assert.strictEqual(prop.mock.accessCount(),2);  assert.strictEqual(prop.mock.accesses[1].type,'set');  assert.strictEqual(prop.mock.accesses[1].value,200);  prop.mock.restore();  assert.strictEqual(obj.foo,42);});

mock.reset()#

Added in: v19.1.0, v18.13.0

This function restores the default behavior of all mocks that were previouslycreated by thisMockTracker and disassociates the mocks from theMockTracker instance. Once disassociated, the mocks can still be used, but theMockTracker instance can no longer be used to reset their behavior orotherwise interact with them.

After each test completes, this function is called on the test context'sMockTracker. If the globalMockTracker is used extensively, calling thisfunction manually is recommended.

mock.restoreAll()#

Added in: v19.1.0, v18.13.0

This function restores the default behavior of all mocks that were previouslycreated by thisMockTracker. Unlikemock.reset(),mock.restoreAll() doesnot disassociate the mocks from theMockTracker instance.

mock.setter(object, methodName[, implementation][, options])#

Added in: v19.3.0, v18.13.0

This function is syntax sugar forMockTracker.method withoptions.setterset totrue.

Class:MockTimers#

History
VersionChanges
v23.1.0

The Mock Timers is now stable.

v20.4.0, v18.19.0

Added in: v20.4.0, v18.19.0

Mocking timers is a technique commonly used in software testing to simulate andcontrol the behavior of timers, such assetInterval andsetTimeout,without actually waiting for the specified time intervals.

MockTimers is also able to mock theDate object.

TheMockTracker provides a top-leveltimers exportwhich is aMockTimers instance.

timers.enable([enableOptions])#

History
VersionChanges
v21.2.0, v20.11.0

Updated parameters to be an option object with available APIs and the default initial epoch.

v20.4.0, v18.19.0

Added in: v20.4.0, v18.19.0

Enables timer mocking for the specified timers.

  • enableOptions<Object> Optional configuration options for enabling timermocking. The following properties are supported:
    • apis<Array> An optional array containing the timers to mock.The currently supported timer values are'setInterval','setTimeout','setImmediate',and'Date'.Default:['setInterval', 'setTimeout', 'setImmediate', 'Date'].If no array is provided, all time related APIs ('setInterval','clearInterval','setTimeout','clearTimeout','setImmediate','clearImmediate', and'Date') will be mocked by default.
    • now<number> |<Date> An optional number or Date object representing theinitial time (in milliseconds) to use as the valueforDate.now().Default:0.

Note: When you enable mocking for a specific timer, its associatedclear function will also be implicitly mocked.

Note: MockingDate will affect the behavior of the mocked timersas they use the same internal clock.

Example usage without setting initial time:

import { mock }from'node:test';mock.timers.enable({apis: ['setInterval'] });const { mock } =require('node:test');mock.timers.enable({apis: ['setInterval'] });

The above example enables mocking for thesetInterval timer andimplicitly mocks theclearInterval function. Only thesetIntervalandclearInterval functions fromnode:timers,node:timers/promises, andglobalThis will be mocked.

Example usage with initial time set

import { mock }from'node:test';mock.timers.enable({apis: ['Date'],now:1000 });const { mock } =require('node:test');mock.timers.enable({apis: ['Date'],now:1000 });

Example usage with initial Date object as time set

import { mock }from'node:test';mock.timers.enable({apis: ['Date'],now:newDate() });const { mock } =require('node:test');mock.timers.enable({apis: ['Date'],now:newDate() });

Alternatively, if you callmock.timers.enable() without any parameters:

All timers ('setInterval','clearInterval','setTimeout','clearTimeout','setImmediate', and'clearImmediate') will be mocked. ThesetInterval,clearInterval,setTimeout,clearTimeout,setImmediate, andclearImmediate functions fromnode:timers,node:timers/promises, andglobalThis will be mocked. As well as the globalDate object.

timers.reset()#

Added in: v20.4.0, v18.19.0

This function restores the default behavior of all mocks that were previouslycreated by thisMockTimers instance and disassociates the mocksfrom theMockTracker instance.

Note: After each test completes, this function is called onthe test context'sMockTracker.

import { mock }from'node:test';mock.timers.reset();const { mock } =require('node:test');mock.timers.reset();

timers[Symbol.dispose]()#

Callstimers.reset().

timers.tick([milliseconds])#

Added in: v20.4.0, v18.19.0

Advances time for all mocked timers.

  • milliseconds<number> The amount of time, in milliseconds,to advance the timers.Default:1.

Note: This diverges from howsetTimeout in Node.js behaves and acceptsonly positive numbers. In Node.js,setTimeout with negative numbers isonly supported for web compatibility reasons.

The following example mocks asetTimeout function andby using.tick advances intime triggering all pending timers.

import assertfrom'node:assert';import { test }from'node:test';test('mocks setTimeout to be executed synchronously without having to actually wait for it',(context) => {const fn = context.mock.fn();  context.mock.timers.enable({apis: ['setTimeout'] });setTimeout(fn,9999);  assert.strictEqual(fn.mock.callCount(),0);// Advance in time  context.mock.timers.tick(9999);  assert.strictEqual(fn.mock.callCount(),1);});const assert =require('node:assert');const { test } =require('node:test');test('mocks setTimeout to be executed synchronously without having to actually wait for it',(context) => {const fn = context.mock.fn();  context.mock.timers.enable({apis: ['setTimeout'] });setTimeout(fn,9999);  assert.strictEqual(fn.mock.callCount(),0);// Advance in time  context.mock.timers.tick(9999);  assert.strictEqual(fn.mock.callCount(),1);});

Alternatively, the.tick function can be called many times

import assertfrom'node:assert';import { test }from'node:test';test('mocks setTimeout to be executed synchronously without having to actually wait for it',(context) => {const fn = context.mock.fn();  context.mock.timers.enable({apis: ['setTimeout'] });const nineSecs =9000;setTimeout(fn, nineSecs);const threeSeconds =3000;  context.mock.timers.tick(threeSeconds);  context.mock.timers.tick(threeSeconds);  context.mock.timers.tick(threeSeconds);  assert.strictEqual(fn.mock.callCount(),1);});const assert =require('node:assert');const { test } =require('node:test');test('mocks setTimeout to be executed synchronously without having to actually wait for it',(context) => {const fn = context.mock.fn();  context.mock.timers.enable({apis: ['setTimeout'] });const nineSecs =9000;setTimeout(fn, nineSecs);const threeSeconds =3000;  context.mock.timers.tick(threeSeconds);  context.mock.timers.tick(threeSeconds);  context.mock.timers.tick(threeSeconds);  assert.strictEqual(fn.mock.callCount(),1);});

Advancing time using.tick will also advance the time for anyDate objectcreated after the mock was enabled (ifDate was also set to be mocked).

import assertfrom'node:assert';import { test }from'node:test';test('mocks setTimeout to be executed synchronously without having to actually wait for it',(context) => {const fn = context.mock.fn();  context.mock.timers.enable({apis: ['setTimeout','Date'] });setTimeout(fn,9999);  assert.strictEqual(fn.mock.callCount(),0);  assert.strictEqual(Date.now(),0);// Advance in time  context.mock.timers.tick(9999);  assert.strictEqual(fn.mock.callCount(),1);  assert.strictEqual(Date.now(),9999);});const assert =require('node:assert');const { test } =require('node:test');test('mocks setTimeout to be executed synchronously without having to actually wait for it',(context) => {const fn = context.mock.fn();  context.mock.timers.enable({apis: ['setTimeout','Date'] });setTimeout(fn,9999);  assert.strictEqual(fn.mock.callCount(),0);  assert.strictEqual(Date.now(),0);// Advance in time  context.mock.timers.tick(9999);  assert.strictEqual(fn.mock.callCount(),1);  assert.strictEqual(Date.now(),9999);});
Using clear functions#

As mentioned, all clear functions from timers (clearTimeout,clearInterval,andclearImmediate) are implicitly mocked. Take a look at this example usingsetTimeout:

import assertfrom'node:assert';import { test }from'node:test';test('mocks setTimeout to be executed synchronously without having to actually wait for it',(context) => {const fn = context.mock.fn();// Optionally choose what to mock  context.mock.timers.enable({apis: ['setTimeout'] });const id =setTimeout(fn,9999);// Implicitly mocked as wellclearTimeout(id);  context.mock.timers.tick(9999);// As that setTimeout was cleared the mock function will never be called  assert.strictEqual(fn.mock.callCount(),0);});const assert =require('node:assert');const { test } =require('node:test');test('mocks setTimeout to be executed synchronously without having to actually wait for it',(context) => {const fn = context.mock.fn();// Optionally choose what to mock  context.mock.timers.enable({apis: ['setTimeout'] });const id =setTimeout(fn,9999);// Implicitly mocked as wellclearTimeout(id);  context.mock.timers.tick(9999);// As that setTimeout was cleared the mock function will never be called  assert.strictEqual(fn.mock.callCount(),0);});
Working with Node.js timers modules#

Once you enable mocking timers,node:timers,node:timers/promises modules,and timers from the Node.js global context are enabled:

Note: Destructuring functions such asimport { setTimeout } from 'node:timers' is currentlynot supported by this API.

import assertfrom'node:assert';import { test }from'node:test';import nodeTimersfrom'node:timers';import nodeTimersPromisesfrom'node:timers/promises';test('mocks setTimeout to be executed synchronously without having to actually wait for it',async (context) => {const globalTimeoutObjectSpy = context.mock.fn();const nodeTimerSpy = context.mock.fn();const nodeTimerPromiseSpy = context.mock.fn();// Optionally choose what to mock  context.mock.timers.enable({apis: ['setTimeout'] });setTimeout(globalTimeoutObjectSpy,9999);  nodeTimers.setTimeout(nodeTimerSpy,9999);const promise = nodeTimersPromises.setTimeout(9999).then(nodeTimerPromiseSpy);// Advance in time  context.mock.timers.tick(9999);  assert.strictEqual(globalTimeoutObjectSpy.mock.callCount(),1);  assert.strictEqual(nodeTimerSpy.mock.callCount(),1);await promise;  assert.strictEqual(nodeTimerPromiseSpy.mock.callCount(),1);});const assert =require('node:assert');const { test } =require('node:test');const nodeTimers =require('node:timers');const nodeTimersPromises =require('node:timers/promises');test('mocks setTimeout to be executed synchronously without having to actually wait for it',async (context) => {const globalTimeoutObjectSpy = context.mock.fn();const nodeTimerSpy = context.mock.fn();const nodeTimerPromiseSpy = context.mock.fn();// Optionally choose what to mock  context.mock.timers.enable({apis: ['setTimeout'] });setTimeout(globalTimeoutObjectSpy,9999);  nodeTimers.setTimeout(nodeTimerSpy,9999);const promise = nodeTimersPromises.setTimeout(9999).then(nodeTimerPromiseSpy);// Advance in time  context.mock.timers.tick(9999);  assert.strictEqual(globalTimeoutObjectSpy.mock.callCount(),1);  assert.strictEqual(nodeTimerSpy.mock.callCount(),1);await promise;  assert.strictEqual(nodeTimerPromiseSpy.mock.callCount(),1);});

In Node.js,setInterval fromnode:timers/promisesis anAsyncGenerator and is also supported by this API:

import assertfrom'node:assert';import { test }from'node:test';import nodeTimersPromisesfrom'node:timers/promises';test('should tick five times testing a real use case',async (context) => {  context.mock.timers.enable({apis: ['setInterval'] });const expectedIterations =3;const interval =1000;const startedAt =Date.now();asyncfunctionrun() {const times = [];forawait (const timeof nodeTimersPromises.setInterval(interval, startedAt)) {      times.push(time);if (times.length === expectedIterations)break;    }return times;  }const r =run();  context.mock.timers.tick(interval);  context.mock.timers.tick(interval);  context.mock.timers.tick(interval);const timeResults =await r;  assert.strictEqual(timeResults.length, expectedIterations);for (let it =1; it < expectedIterations; it++) {    assert.strictEqual(timeResults[it -1], startedAt + (interval * it));  }});const assert =require('node:assert');const { test } =require('node:test');const nodeTimersPromises =require('node:timers/promises');test('should tick five times testing a real use case',async (context) => {  context.mock.timers.enable({apis: ['setInterval'] });const expectedIterations =3;const interval =1000;const startedAt =Date.now();asyncfunctionrun() {const times = [];forawait (const timeof nodeTimersPromises.setInterval(interval, startedAt)) {      times.push(time);if (times.length === expectedIterations)break;    }return times;  }const r =run();  context.mock.timers.tick(interval);  context.mock.timers.tick(interval);  context.mock.timers.tick(interval);const timeResults =await r;  assert.strictEqual(timeResults.length, expectedIterations);for (let it =1; it < expectedIterations; it++) {    assert.strictEqual(timeResults[it -1], startedAt + (interval * it));  }});

timers.runAll()#

Added in: v20.4.0, v18.19.0

Triggers all pending mocked timers immediately. If theDate object is alsomocked, it will also advance theDate object to the furthest timer's time.

The example below triggers all pending timers immediately,causing them to execute without any delay.

import assertfrom'node:assert';import { test }from'node:test';test('runAll functions following the given order',(context) => {  context.mock.timers.enable({apis: ['setTimeout','Date'] });const results = [];setTimeout(() => results.push(1),9999);// Notice that if both timers have the same timeout,// the order of execution is guaranteedsetTimeout(() => results.push(3),8888);setTimeout(() => results.push(2),8888);  assert.deepStrictEqual(results, []);  context.mock.timers.runAll();  assert.deepStrictEqual(results, [3,2,1]);// The Date object is also advanced to the furthest timer's time  assert.strictEqual(Date.now(),9999);});const assert =require('node:assert');const { test } =require('node:test');test('runAll functions following the given order',(context) => {  context.mock.timers.enable({apis: ['setTimeout','Date'] });const results = [];setTimeout(() => results.push(1),9999);// Notice that if both timers have the same timeout,// the order of execution is guaranteedsetTimeout(() => results.push(3),8888);setTimeout(() => results.push(2),8888);  assert.deepStrictEqual(results, []);  context.mock.timers.runAll();  assert.deepStrictEqual(results, [3,2,1]);// The Date object is also advanced to the furthest timer's time  assert.strictEqual(Date.now(),9999);});

Note: TherunAll() function is specifically designed fortriggering timers in the context of timer mocking.It does not have any effect on real-time systemclocks or actual timers outside of the mocking environment.

timers.setTime(milliseconds)#

Added in: v21.2.0, v20.11.0

Sets the current Unix timestamp that will be used as reference for any mockedDate objects.

import assertfrom'node:assert';import { test }from'node:test';test('runAll functions following the given order',(context) => {const now =Date.now();const setTime =1000;// Date.now is not mocked  assert.deepStrictEqual(Date.now(), now);  context.mock.timers.enable({apis: ['Date'] });  context.mock.timers.setTime(setTime);// Date.now is now 1000  assert.strictEqual(Date.now(), setTime);});const assert =require('node:assert');const { test } =require('node:test');test('setTime replaces current time',(context) => {const now =Date.now();const setTime =1000;// Date.now is not mocked  assert.deepStrictEqual(Date.now(), now);  context.mock.timers.enable({apis: ['Date'] });  context.mock.timers.setTime(setTime);// Date.now is now 1000  assert.strictEqual(Date.now(), setTime);});
Dates and Timers working together#

Dates and timer objects are dependent on each other. If you usesetTime() topass the current time to the mockedDate object, the set timers withsetTimeout andsetInterval willnot be affected.

However, thetick methodwill advance the mockedDate object.

import assertfrom'node:assert';import { test }from'node:test';test('runAll functions following the given order',(context) => {  context.mock.timers.enable({apis: ['setTimeout','Date'] });const results = [];setTimeout(() => results.push(1),9999);  assert.deepStrictEqual(results, []);  context.mock.timers.setTime(12000);  assert.deepStrictEqual(results, []);// The date is advanced but the timers don't tick  assert.strictEqual(Date.now(),12000);});const assert =require('node:assert');const { test } =require('node:test');test('runAll functions following the given order',(context) => {  context.mock.timers.enable({apis: ['setTimeout','Date'] });const results = [];setTimeout(() => results.push(1),9999);  assert.deepStrictEqual(results, []);  context.mock.timers.setTime(12000);  assert.deepStrictEqual(results, []);// The date is advanced but the timers don't tick  assert.strictEqual(Date.now(),12000);});

Class:TestsStream#

History
VersionChanges
v20.0.0, v19.9.0, v18.17.0

added type to test:pass and test:fail events for when the test is a suite.

v18.9.0, v16.19.0

Added in: v18.9.0, v16.19.0

A successful call torun() method will return a new<TestsStream>object, streaming a series of events representing the execution of the tests.TestsStream will emit events, in the order of the tests definition

Some of the events are guaranteed to be emitted in the same order as the testsare defined, while others are emitted in the order that the tests execute.

Event:'test:coverage'#

  • data<Object>
    • summary<Object> An object containing the coverage report.
      • files<Array> An array of coverage reports for individual files. Eachreport is an object with the following schema:
        • path<string> The absolute path of the file.
        • totalLineCount<number> The total number of lines.
        • totalBranchCount<number> The total number of branches.
        • totalFunctionCount<number> The total number of functions.
        • coveredLineCount<number> The number of covered lines.
        • coveredBranchCount<number> The number of covered branches.
        • coveredFunctionCount<number> The number of covered functions.
        • coveredLinePercent<number> The percentage of lines covered.
        • coveredBranchPercent<number> The percentage of branches covered.
        • coveredFunctionPercent<number> The percentage of functions covered.
        • functions<Array> An array of functions representing functioncoverage.
          • name<string> The name of the function.
          • line<number> The line number where the function is defined.
          • count<number> The number of times the function was called.
        • branches<Array> An array of branches representing branch coverage.
          • line<number> The line number where the branch is defined.
          • count<number> The number of times the branch was taken.
        • lines<Array> An array of lines representing linenumbers and the number of times they were covered.
          • line<number> The line number.
          • count<number> The number of times the line was covered.
      • thresholds<Object> An object containing whether or not the coverage foreach coverage type.
        • function<number> The function coverage threshold.
        • branch<number> The branch coverage threshold.
        • line<number> The line coverage threshold.
      • totals<Object> An object containing a summary of coverage for allfiles.
        • totalLineCount<number> The total number of lines.
        • totalBranchCount<number> The total number of branches.
        • totalFunctionCount<number> The total number of functions.
        • coveredLineCount<number> The number of covered lines.
        • coveredBranchCount<number> The number of covered branches.
        • coveredFunctionCount<number> The number of covered functions.
        • coveredLinePercent<number> The percentage of lines covered.
        • coveredBranchPercent<number> The percentage of branches covered.
        • coveredFunctionPercent<number> The percentage of functions covered.
      • workingDirectory<string> The working directory when code coveragebegan. This is useful for displaying relative path names in case the testschanged the working directory of the Node.js process.
    • nesting<number> The nesting level of the test.

Emitted when code coverage is enabled and all tests have completed.

Event:'test:complete'#

Emitted when a test completes its execution.This event is not emitted in the same order as the tests aredefined.The corresponding declaration ordered events are'test:pass' and'test:fail'.

Event:'test:dequeue'#

  • data<Object>
    • column<number> |<undefined> The column number where the test is defined, orundefined if the test was run through the REPL.
    • file<string> |<undefined> The path of the test file,undefined if test was run through the REPL.
    • line<number> |<undefined> The line number where the test is defined, orundefined if the test was run through the REPL.
    • name<string> The test name.
    • nesting<number> The nesting level of the test.
    • type<string> The test type. Either'suite' or'test'.

Emitted when a test is dequeued, right before it is executed.This event is not guaranteed to be emitted in the same order as the tests aredefined. The corresponding declaration ordered event is'test:start'.

Event:'test:diagnostic'#

  • data<Object>
    • column<number> |<undefined> The column number where the test is defined, orundefined if the test was run through the REPL.
    • file<string> |<undefined> The path of the test file,undefined if test was run through the REPL.
    • line<number> |<undefined> The line number where the test is defined, orundefined if the test was run through the REPL.
    • message<string> The diagnostic message.
    • nesting<number> The nesting level of the test.
    • level<string> The severity level of the diagnostic message.Possible values are:
      • 'info': Informational messages.
      • 'warn': Warnings.
      • 'error': Errors.

Emitted whencontext.diagnostic is called.This event is guaranteed to be emitted in the same order as the tests aredefined.

Event:'test:enqueue'#

  • data<Object>
    • column<number> |<undefined> The column number where the test is defined, orundefined if the test was run through the REPL.
    • file<string> |<undefined> The path of the test file,undefined if test was run through the REPL.
    • line<number> |<undefined> The line number where the test is defined, orundefined if the test was run through the REPL.
    • name<string> The test name.
    • nesting<number> The nesting level of the test.
    • type<string> The test type. Either'suite' or'test'.

Emitted when a test is enqueued for execution.

Event:'test:fail'#

Emitted when a test fails.This event is guaranteed to be emitted in the same order as the tests aredefined.The corresponding execution ordered event is'test:complete'.

Event:'test:pass'#

Emitted when a test passes.This event is guaranteed to be emitted in the same order as the tests aredefined.The corresponding execution ordered event is'test:complete'.

Event:'test:plan'#

  • data<Object>
    • column<number> |<undefined> The column number where the test is defined, orundefined if the test was run through the REPL.
    • file<string> |<undefined> The path of the test file,undefined if test was run through the REPL.
    • line<number> |<undefined> The line number where the test is defined, orundefined if the test was run through the REPL.
    • nesting<number> The nesting level of the test.
    • count<number> The number of subtests that have ran.

Emitted when all subtests have completed for a given test.This event is guaranteed to be emitted in the same order as the tests aredefined.

Event:'test:start'#

  • data<Object>
    • column<number> |<undefined> The column number where the test is defined, orundefined if the test was run through the REPL.
    • file<string> |<undefined> The path of the test file,undefined if test was run through the REPL.
    • line<number> |<undefined> The line number where the test is defined, orundefined if the test was run through the REPL.
    • name<string> The test name.
    • nesting<number> The nesting level of the test.

Emitted when a test starts reporting its own and its subtests status.This event is guaranteed to be emitted in the same order as the tests aredefined.The corresponding execution ordered event is'test:dequeue'.

Event:'test:stderr'#

Emitted when a running test writes tostderr.This event is only emitted if--test flag is passed.This event is not guaranteed to be emitted in the same order as the tests aredefined.

Event:'test:stdout'#

Emitted when a running test writes tostdout.This event is only emitted if--test flag is passed.This event is not guaranteed to be emitted in the same order as the tests aredefined.

Event:'test:summary'#

  • data<Object>
    • counts<Object> An object containing the counts of various test results.
      • cancelled<number> The total number of cancelled tests.
      • failed<number> The total number of failed tests.
      • passed<number> The total number of passed tests.
      • skipped<number> The total number of skipped tests.
      • suites<number> The total number of suites run.
      • tests<number> The total number of tests run, excluding suites.
      • todo<number> The total number of TODO tests.
      • topLevel<number> The total number of top level tests and suites.
    • duration_ms<number> The duration of the test run in milliseconds.
    • file<string> |<undefined> The path of the test file that generated thesummary. If the summary corresponds to multiple files, this value isundefined.
    • success<boolean> Indicates whether or not the test run is consideredsuccessful or not. If any error condition occurs, such as a failing test orunmet coverage threshold, this value will be set tofalse.

Emitted when a test run completes. This event contains metrics pertaining tothe completed test run, and is useful for determining if a test run passed orfailed. If process-level test isolation is used, a'test:summary' event isgenerated for each test file in addition to a final cumulative summary.

Event:'test:watch:drained'#

Emitted when no more tests are queued for execution in watch mode.

Event:'test:watch:restarted'#

Emitted when one or more tests are restarted due to a file change in watch mode.

Class:TestContext#

History
VersionChanges
v20.1.0, v18.17.0

Thebefore function was added to TestContext.

v18.0.0, v16.17.0

Added in: v18.0.0, v16.17.0

An instance ofTestContext is passed to each test function in order tointeract with the test runner. However, theTestContext constructor is notexposed as part of the API.

context.before([fn][, options])#

Added in: v20.1.0, v18.17.0
  • fn<Function> |<AsyncFunction> The hook function. The first argumentto this function is aTestContext object. If the hook uses callbacks,the callback function is passed as the second argument.Default: A no-opfunction.
  • options<Object> Configuration options for the hook. The followingproperties are supported:
    • signal<AbortSignal> Allows aborting an in-progress hook.
    • timeout<number> A number of milliseconds the hook will fail after.If unspecified, subtests inherit this value from their parent.Default:Infinity.

This function is used to create a hook running beforesubtest of the current test.

context.beforeEach([fn][, options])#

Added in: v18.8.0, v16.18.0
  • fn<Function> |<AsyncFunction> The hook function. The first argumentto this function is aTestContext object. If the hook uses callbacks,the callback function is passed as the second argument.Default: A no-opfunction.
  • options<Object> Configuration options for the hook. The followingproperties are supported:
    • signal<AbortSignal> Allows aborting an in-progress hook.
    • timeout<number> A number of milliseconds the hook will fail after.If unspecified, subtests inherit this value from their parent.Default:Infinity.

This function is used to create a hook runningbefore each subtest of the current test.

test('top level test',async (t) => {  t.beforeEach((t) => t.diagnostic(`about to run${t.name}`));await t.test('This is a subtest',(t) => {// Some relevant assertion here    },  );});

context.after([fn][, options])#

Added in: v19.3.0, v18.13.0
  • fn<Function> |<AsyncFunction> The hook function. The first argumentto this function is aTestContext object. If the hook uses callbacks,the callback function is passed as the second argument.Default: A no-opfunction.
  • options<Object> Configuration options for the hook. The followingproperties are supported:
    • signal<AbortSignal> Allows aborting an in-progress hook.
    • timeout<number> A number of milliseconds the hook will fail after.If unspecified, subtests inherit this value from their parent.Default:Infinity.

This function is used to create a hook that runs after the current testfinishes.

test('top level test',async (t) => {  t.after((t) => t.diagnostic(`finished running${t.name}`));// Some relevant assertion here});

context.afterEach([fn][, options])#

Added in: v18.8.0, v16.18.0
  • fn<Function> |<AsyncFunction> The hook function. The first argumentto this function is aTestContext object. If the hook uses callbacks,the callback function is passed as the second argument.Default: A no-opfunction.
  • options<Object> Configuration options for the hook. The followingproperties are supported:
    • signal<AbortSignal> Allows aborting an in-progress hook.
    • timeout<number> A number of milliseconds the hook will fail after.If unspecified, subtests inherit this value from their parent.Default:Infinity.

This function is used to create a hook runningafter each subtest of the current test.

test('top level test',async (t) => {  t.afterEach((t) => t.diagnostic(`finished running${t.name}`));await t.test('This is a subtest',(t) => {// Some relevant assertion here    },  );});

context.assert#

Added in: v22.2.0, v20.15.0

An object containing assertion methods bound tocontext. The top-levelfunctions from thenode:assert module are exposed here for the purpose ofcreating test plans.

test('test',(t) => {  t.plan(1);  t.assert.strictEqual(true,true);});
context.assert.fileSnapshot(value, path[, options])#
Added in: v23.7.0, v22.14.0
  • value<any> A value to serialize to a string. If Node.js was started withthe--test-update-snapshots flag, the serialized value is written topath. Otherwise, the serialized value is compared to the contents of theexisting snapshot file.
  • path<string> The file where the serializedvalue is written.
  • options<Object> Optional configuration options. The following propertiesare supported:
    • serializers<Array> An array of synchronous functions used to serializevalue into a string.value is passed as the only argument to the firstserializer function. The return value of each serializer is passed as inputto the next serializer. Once all serializers have run, the resulting valueis coerced to a string.Default: If no serializers are provided, thetest runner's default serializers are used.

This function serializesvalue and writes it to the file specified bypath.

test('snapshot test with default serialization',(t) => {  t.assert.fileSnapshot({value1:1,value2:2 },'./snapshots/snapshot.json');});

This function differs fromcontext.assert.snapshot() in the following ways:

  • The snapshot file path is explicitly provided by the user.
  • Each snapshot file is limited to a single snapshot value.
  • No additional escaping is performed by the test runner.

These differences allow snapshot files to better support features such as syntaxhighlighting.

context.assert.snapshot(value[, options])#
Added in: v22.3.0
  • value<any> A value to serialize to a string. If Node.js was started withthe--test-update-snapshots flag, the serialized value is written tothe snapshot file. Otherwise, the serialized value is compared to thecorresponding value in the existing snapshot file.
  • options<Object> Optional configuration options. The following propertiesare supported:
    • serializers<Array> An array of synchronous functions used to serializevalue into a string.value is passed as the only argument to the firstserializer function. The return value of each serializer is passed as inputto the next serializer. Once all serializers have run, the resulting valueis coerced to a string.Default: If no serializers are provided, thetest runner's default serializers are used.

This function implements assertions for snapshot testing.

test('snapshot test with default serialization',(t) => {  t.assert.snapshot({value1:1,value2:2 });});test('snapshot test with custom serialization',(t) => {  t.assert.snapshot({value3:3,value4:4 }, {serializers: [(value) =>JSON.stringify(value)],  });});

context.diagnostic(message)#

Added in: v18.0.0, v16.17.0

This function is used to write diagnostics to the output. Any diagnosticinformation is included at the end of the test's results. This function doesnot return a value.

test('top level test',(t) => {  t.diagnostic('A diagnostic message');});

context.filePath#

Added in: v22.6.0, v20.16.0

The absolute path of the test file that created the current test. If a test fileimports additional modules that generate tests, the imported tests will returnthe path of the root test file.

context.fullName#

Added in: v22.3.0, v20.16.0

The name of the test and each of its ancestors, separated by>.

context.name#

Added in: v18.8.0, v16.18.0

The name of the test.

context.passed#

Added in: v21.7.0, v20.12.0
  • Type:<boolean>false before the test is executed, e.g. in abeforeEach hook.

Indicated whether the test succeeded.

context.error#

Added in: v21.7.0, v20.12.0

The failure reason for the test/case; wrapped and available viacontext.error.cause.

context.attempt#

Added in: v25.0.0

Number of times the test has been attempted.

context.plan(count[,options])#

History
VersionChanges
v23.9.0, v22.15.0

Add theoptions parameter.

v23.4.0, v22.13.0

This function is no longer experimental.

v22.2.0, v20.15.0

Added in: v22.2.0, v20.15.0

  • count<number> The number of assertions and subtests that are expected to run.
  • options<Object> Additional options for the plan.
    • wait<boolean> |<number> The wait time for the plan:
      • Iftrue, the plan waits indefinitely for all assertions and subtests to run.
      • Iffalse, the plan performs an immediate check after the test function completes,without waiting for any pending assertions or subtests.Any assertions or subtests that complete after this check will not be counted towards the plan.
      • If a number, it specifies the maximum wait time in millisecondsbefore timing out while waiting for expected assertions and subtests to be matched.If the timeout is reached, the test will fail.Default:false.

This function is used to set the number of assertions and subtests that are expected to runwithin the test. If the number of assertions and subtests that run does not match theexpected count, the test will fail.

Note: To make sure assertions are tracked,t.assert must be used instead ofassert directly.

test('top level test',(t) => {  t.plan(2);  t.assert.ok('some relevant assertion here');  t.test('subtest',() => {});});

When working with asynchronous code, theplan function can be used to ensure that thecorrect number of assertions are run:

test('planning with streams',(t, done) => {function*generate() {yield'a';yield'b';yield'c';  }const expected = ['a','b','c'];  t.plan(expected.length);const stream =Readable.from(generate());  stream.on('data',(chunk) => {    t.assert.strictEqual(chunk, expected.shift());  });  stream.on('end',() => {done();  });});

When using thewait option, you can control how long the test will wait for the expected assertions.For example, setting a maximum wait time ensures that the test will wait for asynchronous assertionsto complete within the specified timeframe:

test('plan with wait: 2000 waits for async assertions',(t) => {  t.plan(1, {wait:2000 });// Waits for up to 2 seconds for the assertion to complete.constasyncActivity = () => {setTimeout(() => {      t.assert.ok(true,'Async assertion completed within the wait time');    },1000);// Completes after 1 second, within the 2-second wait time.  };asyncActivity();// The test will pass because the assertion is completed in time.});

Note: If await timeout is specified, it begins counting down only after the test function finishes executing.

context.runOnly(shouldRunOnlyTests)#

Added in: v18.0.0, v16.17.0
  • shouldRunOnlyTests<boolean> Whether or not to runonly tests.

IfshouldRunOnlyTests is truthy, the test context will only run tests thathave theonly option set. Otherwise, all tests are run. If Node.js was notstarted with the--test-only command-line option, this function is ano-op.

test('top level test',(t) => {// The test context can be set to run subtests with the 'only' option.  t.runOnly(true);returnPromise.all([    t.test('this subtest is now skipped'),    t.test('this subtest is run', {only:true }),  ]);});

context.signal#

Added in: v18.7.0, v16.17.0

Can be used to abort test subtasks when the test has been aborted.

test('top level test',async (t) => {awaitfetch('some/uri', {signal: t.signal });});

context.skip([message])#

Added in: v18.0.0, v16.17.0

This function causes the test's output to indicate the test as skipped. Ifmessage is provided, it is included in the output. Callingskip() doesnot terminate execution of the test function. This function does not return avalue.

test('top level test',(t) => {// Make sure to return here as well if the test contains additional logic.  t.skip('this is skipped');});

context.todo([message])#

Added in: v18.0.0, v16.17.0

This function adds aTODO directive to the test's output. Ifmessage isprovided, it is included in the output. Callingtodo() does not terminateexecution of the test function. This function does not return a value.

test('top level test',(t) => {// This test is marked as `TODO`  t.todo('this is a todo');});

context.test([name][, options][, fn])#

History
VersionChanges
v18.8.0, v16.18.0

Add asignal option.

v18.7.0, v16.17.0

Add atimeout option.

v18.0.0, v16.17.0

Added in: v18.0.0, v16.17.0

  • name<string> The name of the subtest, which is displayed when reportingtest results.Default: Thename property offn, or'<anonymous>' iffn does not have a name.
  • options<Object> Configuration options for the subtest. The followingproperties are supported:
    • concurrency<number> |<boolean> |<null> If a number is provided,then that many tests would run asynchronously (they are still managed by the single-threaded event loop).Iftrue, it would run all subtests in parallel.Iffalse, it would only run one test at a time.If unspecified, subtests inherit this value from their parent.Default:null.
    • only<boolean> If truthy, and the test context is configured to runonly tests, then this test will be run. Otherwise, the test is skipped.Default:false.
    • signal<AbortSignal> Allows aborting an in-progress test.
    • skip<boolean> |<string> If truthy, the test is skipped. If a string isprovided, that string is displayed in the test results as the reason forskipping the test.Default:false.
    • todo<boolean> |<string> If truthy, the test marked asTODO. If a stringis provided, that string is displayed in the test results as the reason whythe test isTODO.Default:false.
    • timeout<number> A number of milliseconds the test will fail after.If unspecified, subtests inherit this value from their parent.Default:Infinity.
    • plan<number> The number of assertions and subtests expected to be run in the test.If the number of assertions run in the test does not match the numberspecified in the plan, the test will fail.Default:undefined.
  • fn<Function> |<AsyncFunction> The function under test. The first argumentto this function is aTestContext object. If the test uses callbacks,the callback function is passed as the second argument.Default: A no-opfunction.
  • Returns:<Promise> Fulfilled withundefined once the test completes.

This function is used to create subtests under the current test. This functionbehaves in the same fashion as the top leveltest() function.

test('top level test',async (t) => {await t.test('This is a subtest',    {only:false,skip:false,concurrency:1,todo:false,plan:1 },(t) => {      t.assert.ok('some relevant assertion here');    },  );});

context.waitFor(condition[, options])#

Added in: v23.7.0, v22.14.0
  • condition<Function> |<AsyncFunction> An assertion function that is invokedperiodically until it completes successfully or the defined polling timeoutelapses. Successful completion is defined as not throwing or rejecting. Thisfunction does not accept any arguments, and is allowed to return any value.
  • options<Object> An optional configuration object for the polling operation.The following properties are supported:
    • interval<number> The number of milliseconds to wait after an unsuccessfulinvocation ofcondition before trying again.Default:50.
    • timeout<number> The poll timeout in milliseconds. Ifcondition has notsucceeded by the time this elapses, an error occurs.Default:1000.
  • Returns:<Promise> Fulfilled with the value returned bycondition.

This method polls acondition function until that function either returnssuccessfully or the operation times out.

Class:SuiteContext#

Added in: v18.7.0, v16.17.0

An instance ofSuiteContext is passed to each suite function in order tointeract with the test runner. However, theSuiteContext constructor is notexposed as part of the API.

context.filePath#

Added in: v22.6.0

The absolute path of the test file that created the current suite. If a testfile imports additional modules that generate suites, the imported suites willreturn the path of the root test file.

context.fullName#

Added in: v22.3.0, v20.16.0

The name of the suite and each of its ancestors, separated by>.

context.name#

Added in: v18.8.0, v16.18.0

The name of the suite.

context.signal#

Added in: v18.7.0, v16.17.0

Can be used to abort test subtasks when the test has been aborted.