Overload EXPECT_NSEQ to handle NSRect.

Overload EXPECT_NSEQ to handle NSRect/NSPoint.

Previously, the typical pattern is:
EXPECT_TRUE(NSEqualRects(expected_rect, actual_rect));
But this does not print useful information upon failure.

This CL allows tests to compare NSRects with:
EXPECT_NSEQ(expected_rect, actual_rect);
which prints the NSRect upon failure.

Similarly for NSPoint.

BUG=None

Committed: https://crrev.com/b22ade8600b7fb6863a197e35b5c0aeeae61d51e
Cr-Commit-Position: refs/heads/master@{#336939}

[jackhou1, 2015-06-26 04:27:56]

jackhou@chromium.org changed reviewers:
+ tapted@chromium.org

[jackhou1, 2015-06-26 04:27:57]

tapted, PTAL

[tapted, 2015-06-26 06:26:07]

lgtm - seems reasonable, but I'm not too familiar with gtest internals :/. Maybe
get a second opinion from rsesek, since he wrote the NSEQ macros (maybe we want
to do NSPoint at the same time..?).

And there's a comment at
https://code.google.com/p/googletest/issues/detail?id=303 regarding the NSEQ
macros - something about using gmock matchers, but I don't think we want a
dependency on gmock.

Note that something similar was done for geometry types in
http://crrev.com/282270 . The execution is a bit different (PrintTo etc.), but
I'm pretty sure it relies on an operator==(). I think what you have here is
appropriate for NSRect.

https://codereview.chromium.org/1211283003/diff/1/testing/gtest_mac.h
File testing/gtest_mac.h (right):

https://codereview.chromium.org/1211283003/diff/1/testing/gtest_mac.h#newcode33
testing/gtest_mac.h:33: // NSEqualRects. Used to implement {ASSERT|EXPECT}_EQ().
{ASSERT|EXPECT}_NSEQ?

https://codereview.chromium.org/1211283003/diff/1/testing/gtest_mac.h#newcode40
testing/gtest_mac.h:40: // NSEqualRects. Used to implement {ASSERT|EXPECT}_EQ().
EQ->NE

or, probably, {ASSERT|EXPECT}_NSNE?

[tapted, 2015-06-26 06:27:59]

oh, there's also an ios compile failure.

You probably need

#if defined(OS_IOS)
#include <CoreGraphics/CoreGraphics.h>
#endif

(NSRect is in CoreGraphics on Mac since ~10.8 or something but the header is
buried under ApplicationServices before that, so #ifdef required while we still
build against 10.6)

[jackhou1, 2015-06-30 00:33:13]

> maybe we want to do NSPoint at the same time..?

Done.

> oh, there's also an ios compile failure.
> 
> You probably need
> 
> #if defined(OS_IOS)
> #include <CoreGraphics/CoreGraphics.h>
> #endif

This didn't seem to help. I couldn't find NSRect defined anywhere in
iPhoneOS8.3.sdk. I've just used if-defs to remove the NSRect/NSPoint overloads
from IOS.

https://codereview.chromium.org/1211283003/diff/1/testing/gtest_mac.h
File testing/gtest_mac.h (right):

https://codereview.chromium.org/1211283003/diff/1/testing/gtest_mac.h#newcode33
testing/gtest_mac.h:33: // NSEqualRects. Used to implement {ASSERT|EXPECT}_EQ().
On 2015/06/26 06:26:07, tapted wrote:
> {ASSERT|EXPECT}_NSEQ?

Done.

https://codereview.chromium.org/1211283003/diff/1/testing/gtest_mac.h#newcode40
testing/gtest_mac.h:40: // NSEqualRects. Used to implement {ASSERT|EXPECT}_EQ().
On 2015/06/26 06:26:07, tapted wrote:
> EQ->NE
> 
> or, probably, {ASSERT|EXPECT}_NSNE?

Done.

[tapted, 2015-06-30 00:50:58]

tapted@chromium.org changed reviewers:
+ rsesek@chromium.org

[tapted, 2015-06-30 00:50:59]

+rsesek for a second opinion (since you added the original NSNE)

and (copying from https://codereview.chromium.org/1211283003/#msg3 )

there's a comment at
https://code.google.com/p/googletest/issues/detail?id=303 regarding the NSEQ
macros - something about using gmock matchers, but I don't think we want a
dependency on gmock.

Note that something similar was done for geometry types in
http://crrev.com/282270 . The execution is a bit different (PrintTo etc.), but
I'm pretty sure it relies on an operator==(). I think what you have here is
appropriate for NSRect.


(changes lgtm)

On 2015/06/30 00:33:13, jackhou1 wrote:
> > maybe we want to do NSPoint at the same time..?
> 
> Done.
> 
> > oh, there's also an ios compile failure.
> > 
> > You probably need
> > 
> > #if defined(OS_IOS)
> > #include <CoreGraphics/CoreGraphics.h>
> > #endif
> 
> This didn't seem to help. I couldn't find NSRect defined anywhere in
> iPhoneOS8.3.sdk. I've just used if-defs to remove the NSRect/NSPoint overloads
> from IOS.

Ah. iOS has CGRect. And I think they basically static-cast to each other
[maybe]. But I doubt there's something convenient like NSStringFromRect for
CGRect.

Guarding iOS seems reasonable.

[Robert Sesek, 2015-06-30 21:24:14]

LGTM

[jackhou1, 2015-07-01 00:10:16]

The CQ bit was checked by jackhou@chromium.org

[commit-bot: I haz the power, 2015-07-01 00:10:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1211283003/120001

[commit-bot: I haz the power, 2015-07-01 00:44:49]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2015-07-01 00:45:51]

Patchset 7 (id:??) landed as
https://crrev.com/b22ade8600b7fb6863a197e35b5c0aeeae61d51e
Cr-Commit-Position: refs/heads/master@{#336939}