29

I am unable to understand why the test case failed in case of summing double numbers or floats. It works very finely for the integer data type.

//the method in simple_method.h

double sum ( double a, double b)
{
    double res = a+b;
    return res;
}

// the test case for this method

TEST(simpleSum, sumOfFloat)
{
    EXPECT_EQ(4.56, sum(0.56, 4.0));
}

// the output is

Running main() from gtest_main.cc
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from simpleSum
[ RUN      ] simpleSum.sumOfFloat
/home/pcadmin/Desktop/so/so3/simple_method_test.cpp:7: Failure
Value of: sum(0.56, 4.0)
  Actual: 4.56
Expected: 4.56
[  FAILED  ] simpleSum.sumOfFloat (0 ms)
[----------] 1 test from simpleSum (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] simpleSum.sumOfFloat

 1 FAILED TEST
BenMorel
  • 31,815
  • 47
  • 169
  • 296
suma
  • 563
  • 3
  • 6
  • 13

4 Answers4

48

Use EXPECT_NEAR or the DoubleEq matcher instead. Floating point operations can lead to rounding errors which makes the results ever so slightly different.

david
  • 1,242
  • 14
  • 28
congusbongus
  • 12,079
  • 5
  • 68
  • 93
  • `EXPECT_NEAR` has a broken link. I was able to find this part of documentation instead: https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#floating-point-macros – kyriakosSt Oct 10 '18 at 15:11
  • I refrained as I didn't know if you could get the original link working – kyriakosSt Oct 11 '18 at 09:07
  • For me only `EXPECT_NEAR` worked. Even when the difference was less than `10^(-5)` ``EXPECT_DOUBLE_EQ` failed – joepol Mar 15 '20 at 12:44
33

See documentation for Floating Point Comparison

EXPECT_EQ uses exact match. But you cannot match two floating numbers exactly. (at least with ease.)

You can use EXPECT_FLOAT_EQ or EXPECT_DOUBLE_EQ. (with heuristic bounds) Also, you may use EXPECT_NEAR with specific bounds.

DrBuck
  • 762
  • 6
  • 22
Jinuk Kim
  • 705
  • 5
  • 5
4

From https://testing.googleblog.com/2008/10/tott-floating-point-comparison.html

When comparing floating-point values, checking for equality might lead to unexpected results. Rounding errors can lead to a result that is close to the expected one, but not equal. As a consequence, an assertion might fail when checking for equality of two floating-point quantities even if the program is implemented correctly.

The Google C++ Testing Framework provides functions for comparing two floating-point quantities up to a given precision.

ASSERT_FLOAT_EQ(expected, actual);
ASSERT_DOUBLE_EQ(expected, actual);

EXPECT_FLOAT_EQ(expected, actual);
EXPECT_DOUBLE_EQ(expected, actual);

In your case,

TEST(simpleSum, sumOfFloat)
{
    EXPECT_DOUBLE_EQ(4.56, sum(0.56, 4.0));
}
Syaiful Nizam Yahya
  • 3,914
  • 11
  • 48
  • 67
  • 1
    the thing I don't like about EXPECT_DOUBLE_EQ() is that you cannot provide an error delta. Sometimes a test will still fail because of floating point error, esp accumulated error. – voxoid Jul 10 '20 at 17:39
-5

This is just a bug in Googletest. Text output should prove the failure, but format of it is not specified precisely.

  • 3
    This is not a bug in gtest, but a property of numbers in floating point representation. Here's a reference https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html – alexisrozhkov Apr 20 '16 at 12:42
  • I believe the poster is saying that it's a bug that the text output doesn't have enough decimal places to show that the two do not match. Not that the numbers should match. – Alex Wilson Sep 13 '16 at 14:16