Use EXPECT_EQ when possible.

cc/test/geometry_test_utils.h

 // Copyright 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CC_TEST_GEOMETRY_TEST_UTILS_H_
 #define CC_TEST_GEOMETRY_TEST_UTILS_H_
 
 namespace gfx {
 class Transform;
 }
@@ skipping 11 matching lines @@
 } while (false)
 
 #define EXPECT_RECT_NEAR(expected, actual, abs_error) \
 do { \
   EXPECT_NEAR((expected).x(), (actual).x(), (abs_error)); \
   EXPECT_NEAR((expected).y(), (actual).y(), (abs_error)); \
   EXPECT_NEAR((expected).width(), (actual).width(), (abs_error)); \
   EXPECT_NEAR((expected).height(), (actual).height(), (abs_error)); \
 } while (false)
 
-#define EXPECT_RECT_EQ(expected, actual) \
-do { \
-  EXPECT_EQ((expected).x(), (actual).x()); \
-  EXPECT_EQ((expected).y(), (actual).y()); \
-  EXPECT_EQ((expected).width(), (actual).width()); \
-  EXPECT_EQ((expected).height(), (actual).height()); \
-} while (false)
-
-#define EXPECT_SIZE_EQ(expected, actual) \
-do { \
-  EXPECT_EQ((expected).width(), (actual).width()); \
-  EXPECT_EQ((expected).height(), (actual).height()); \
-} while (false)
-
-#define EXPECT_POINT_EQ(expected, actual) \
-do { \
-  EXPECT_EQ((expected).x(), (actual).x()); \
-  EXPECT_EQ((expected).y(), (actual).y()); \
-} while (false)
-
-#define EXPECT_POINT3F_EQ(expected, actual) \

[hush (inactive), 2014/12/04 20:10:18]

On second thought, I need to keep EXPECT_POINT3F_EQ here as well. Using
EXPECT_EQ to compare POINT3F might fail due to floating point imprecision. We're
just lucky that the existing POINT3F comparisons are exactly equal.

[danakj, 2014/12/04 20:13:19]

I think it's fine to use EXPECT_EQ, and if a test really needs that inprecision
it can do EXPECT_FLOAT_EQ or something.

-do { \
-  EXPECT_FLOAT_EQ((expected).x(), (actual).x()); \
-  EXPECT_FLOAT_EQ((expected).y(), (actual).y()); \
-  EXPECT_FLOAT_EQ((expected).z(), (actual).z()); \
-} while (false)
-
 #define EXPECT_VECTOR_EQ(expected, actual) \

[danakj, 2014/12/04 19:34:29]

we could do these vector things too right?

[hush (inactive), 2014/12/04 20:10:18]

no... Right now EXPECT_VECTOR_EQ is treating |expected| and |actual| as
duck-typed objects. So we're using EXPECT_VECTOR_EQ quite liberally to compare
ScrollOffset against Vector2d, ScrollOffset against Size, ScrollOffset against
Rect, etc. This is pretty convenient.

If I replace it with EXPECT_EQ, I need to fix all the call sites to compare with
the same type of object, which is more hassle I think..

[danakj, 2014/12/04 20:13:19]

That sounds.. a bit weird. I'm guessing some places just got missed in the
conversion from Vector2d to ScrollOffset, but let's not do anything with that in
this CL.

 do { \
   EXPECT_EQ((expected).x(), (actual).x()); \
   EXPECT_EQ((expected).y(), (actual).y()); \
 } while (false)
 
 #define EXPECT_VECTOR2DF_EQ(expected, actual) \
 do { \
   EXPECT_FLOAT_EQ((expected).x(), (actual).x()); \
   EXPECT_FLOAT_EQ((expected).y(), (actual).y()); \
 } while (false)
@@ skipping 25 matching lines @@
     ExpectTransformationMatrixEq(expected, actual);       \
   } while (false)
 
 // Should be used in test code only, for convenience. Production code should use
 // the gfx::Transform::GetInverse() API.
 gfx::Transform Inverse(const gfx::Transform& transform);
 
 }  // namespace cc
 
 #endif  // CC_TEST_GEOMETRY_TEST_UTILS_H_