jestjs/jest · error · TypeError

${RECEIVED_COLOR('received')} value must be a number

Error message

${RECEIVED_COLOR('received')} value must be a number

What it means

Thrown by `toBeCloseTo` (matchers.ts:163) when the `received` value — what you passed to `expect(...)` — is not a number. This is a type guard on the actual/observed value, fired after the expected-value check. The matcher cannot do floating-point math on a non-number, so it aborts before producing a misleading pass/fail.

Source

Thrown at packages/expect/src/matchers.ts:164

    const options: MatcherHintOptions = {
      isNot,
      promise: this.promise,
      secondArgument,
      secondArgumentColor: (arg: string) => arg,
    };

    if (typeof expected !== 'number') {
      throw new TypeError(
        matcherErrorMessage(
          matcherHint(matcherName, undefined, undefined, options),
          `${EXPECTED_COLOR('expected')} value must be a number`,
          printWithType('Expected', expected, printExpected),
        ),
      );
    }

    if (typeof received !== 'number') {
      throw new TypeError(
        matcherErrorMessage(
          matcherHint(matcherName, undefined, undefined, options),
          `${RECEIVED_COLOR('received')} value must be a number`,
          printWithType('Received', received, printReceived),
        ),
      );
    }

    let pass: boolean;
    let expectedDiff = 0;
    let receivedDiff = 0;

    if (
      received === Number.POSITIVE_INFINITY &&
      expected === Number.POSITIVE_INFINITY
    ) {
      pass = true; // Infinity - Infinity is NaN
    } else if (

View on GitHub (pinned to 8e6d128e4a)

Solutions

  1. Verify the function under test actually returns a number for the given input (add a console.log or a type check before expect).
  2. If the source genuinely returns a string, coerce with Number()/parseFloat() inside the assertion: expect(Number(result)).toBeCloseTo(...).
  3. Handle the undefined/error path separately rather than asserting on it, e.g. assert the value is defined first.
  4. If NaN is expected to be invalid, use toBeNaN instead of toBeCloseTo.

Example fix

// before
expect(getPrice(item)).toBeCloseTo(9.99); // getPrice returns undefined

// after
const price = getPrice(item);
expect(price).toBeDefined();
expect(Number(price)).toBeCloseTo(9.99);
Defensive patterns

Strategy: validation

Validate before calling

const result = compute();
assert(typeof result === 'number' && Number.isFinite(result));
expect(result).toBeCloseTo(0.3, 5);

Type guard

const isFiniteNumber = (v: unknown): v is number =>
  typeof v === 'number' && Number.isFinite(v);

Prevention

When it happens

Trigger: Calling `expect(value).toBeCloseTo(0.3)` where `value` is a string, null, undefined, an object, an array, or NaN. Common when the function under test returns undefined on an error path, or returns a string like '0.30000'.

Common situations: Async function resolved to undefined because a branch returned early; a parser/formatter returned a string instead of a number; a destructuring bug left the variable undefined; a Number.parseInt misuse produced NaN.

Related errors


AI-assisted analysis of jestjs/jest@8e6d128e4a (2026-08-10). Data as JSON: /api/errors/25776f275d990fbc. Report an issue: GitHub.