Error with EXPECT_EQ for sum of double or float

Question

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

Nazario

Answer 1

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

Sumatra

EXPECT_NEAR has a broken link. I was able to find this part of documentation instead: github.com/google/googletest/blob/master/googletest/docs/… – Navarino

I refrained as I didn't know if you could get the original link working – Navarino

For me only EXPECT_NEAR worked. Even when the difference was less than 10^(-5) ``EXPECT_DOUBLE_EQ` failed – Mcclintock

Answer 2

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.

Incandesce

Answer 3

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));
}

Cynthy

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. – Disenable

"The Google C++ Testing Framework provides functions for comparing two floating-point quantities up to a given precision". Is there any doc for the precision? – Impregnable

@Disenable You can use EXPECT_NEAR if that is your use case – Mauretania

@ZiqiFan The documentation says "to within 4 ULPs". So in C++ terms I would guess 4 * std::numeric_limits<double>::epsilon() – Mauretania

Answer 4

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

Lectionary

This is not a bug in gtest, but a property of numbers in floating point representation. Here's a reference docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html – Becoming

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. – Terwilliger