Decimal numbers in most programming languages (including JS) are internally represented in "floating point number" format. Floating point arithmetic is not exact. For example, the result of 46.5678 - 46 === 0.5678 is false because 46.5678 - 46 only yield a value that is very close to 0.5678. Even changing the order in which the program add/subtract numbers can yield different values.

So the following could happen

  expect( 1.2 + 0.6 + 0.005 ).toEqual( 1.805 );                // This fail
  expect( 1.2 + 0.6 + 0.005 ).toEqual( 1.8049999999999997 );   // This pass
  expect( 0.005 + 0.6 + 1.2 ).toEqual( 1.8049999999999997 );   // This fail

  console.log(1.2 + 0.6 + 0.005 == 1.805);  // false
  console.log(1.2 + 0.6 + 0.005 == 0.005 + 0.6 + 1.2); // false

Can you find a more appropriate way to test a value (that involves decimal number calculations) for equality?

Suggestion: Look up

• Checking equality in floating point arithmetic in JavaScript
• Checking equality in floating point arithmetic with Jest

Hi @cjyuan, Thank you for your feedback. I understand now why decimal values need special handling. toBeCloseTo() is a better choice because it checks that the result is close enough within a small margin, which avoids issues caused by floating‑point rounding.

Note: The default value of the second parameter of toBeCloseTo() is only 2
See: https://jestjs.io/docs/expect#tobeclosetonumber-numdigits

For the default value 2, the test criterion is Math.abs(expected - received) < 0.005, which may not be precise enough in some applications.

This test can verify the function can return a different array.

However, there is a chance that, even though result has incorrect elements (for example, [1, 1, 1]),
the test on line 29 could still pass. Can you figure out why, and then improve the test accordingly?