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
- Verify the function under test actually returns a number for the given input (add a console.log or a type check before expect).
- If the source genuinely returns a string, coerce with Number()/parseFloat() inside the assertion: expect(Number(result)).toBeCloseTo(...).
- Handle the undefined/error path separately rather than asserting on it, e.g. assert the value is defined first.
- 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
- Assert the source function returns a number for the test input before the matcher.
- Add TypeScript return types so undefined leaks are compile errors.
- Unit-test edge inputs separately so undefined returns surface early.
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
- ${EXPECTED_COLOR('expected')} value must be a number
- ${EXPECTED_COLOR('expected')} value must be a function
- ${RECEIVED_COLOR('received')} value must not be null nor und
- ${EXPECTED_COLOR('expected')} value must be a string if ${RE
- ${RECEIVED_COLOR('received')} value must have a length prope
AI-assisted analysis of jestjs/jest@8e6d128e4a (2026-08-10).
Data as JSON: /api/errors/25776f275d990fbc.
Report an issue: GitHub.