This adds adds four macros when compiling using GTEST_OS_MAC:

This adds adds four macros when compiling using GTEST_OS_MAC:
{ASSERT,EXPECT}_NS{NE,EQ}.  These test ObjC objects using |-isEqual:| and
prints failures using the |-description| selector.  This allows for better
debugging output with ObjC++ test cases.

BUG=http://code.google.com/p/googletest/issues/detail?id=303
TEST=Covered by unit tests.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=55180

[Mark Mentovai, 2010-08-05 23:01:15]

lg™

http://codereview.chromium.org/3028047/diff/1/4
File testing/gtest_mac.h (right):

http://codereview.chromium.org/3028047/diff/1/4#newcode5
testing/gtest_mac.h:5: #ifndef TESTING_GTEST_GTEST_MAC_H_
There’s an extra GTEST_ in here now.

[Paweł Hajdan Jr., 2010-08-05 23:34:27]

Oh, have we sent those upstream?

[Robert Sesek, 2010-08-05 23:35:54]

On 2010/08/05 23:34:27, Paweł Hajdan Jr. wrote:
> Oh, have we sent those upstream?

They weren't interested.

https://groups.google.com/group/googletestframework/browse_thread/thread/3ee6...

[Paweł Hajdan Jr., 2010-08-05 23:39:36]

The latest Zhanyong's e-mail has some alternative suggestions. I'd really
like to avoid forking every third party project we have.

On Thu, Aug 5, 2010 at 16:35, <rsesek@chromium.org> wrote:

> On 2010/08/05 23:34:27, Paweł Hajdan Jr. wrote:
>
>> Oh, have we sent those upstream?
>>
>
> They weren't interested.
>
>
>
https://groups.google.com/group/googletestframework/browse_thread/thread/3ee6...
>
>
> http://codereview.chromium.org/3028047/show
>

[Mark Mentovai, 2010-08-05 23:42:54]

Paweł Hajdan, Jr. wrote:
> The latest Zhanyong's e-mail has some alternative suggestions. I'd really
> like to avoid forking every third party project we have.

We’re not forking anything. Upstream gtest lives in testing/gtest.
We’re adding our own support bits to testing, but not to
testing/gtest. This is precisely what one of Zhanyong’s suggestions
is.

[Robert Sesek, 2010-08-05 23:43:35]

On 2010/08/05 23:39:36, Paweł Hajdan Jr. wrote:
> The latest Zhanyong's e-mail has some alternative suggestions. I'd really
> like to avoid forking every third party project we have.

This is not a fork.  This is an extension that they wouldn't accept upstream.  A
macro makes the most sense for our project because AFAICT we do not use matchers
anywhere.  As a Mac developer, I don't want a less-fluent, uncommon syntax to
perform common assertions.  Either way, this will land pretty much as-is (once I
fix the compile).

[Robert Sesek, 2010-08-05 23:47:13]

This fixes compile because NeFailure is no longer in the CL.

http://codereview.chromium.org/3028047/diff/1/4
File testing/gtest_mac.h (right):

http://codereview.chromium.org/3028047/diff/1/4#newcode5
testing/gtest_mac.h:5: #ifndef TESTING_GTEST_GTEST_MAC_H_
On 2010/08/05 23:01:15, Mark Mentovai wrote:
> There’s an extra GTEST_ in here now.

Done.

[Mark Mentovai, 2010-08-05 23:49:44]

LGTM

[Avi (use Gerrit), 2010-08-05 23:51:15]

http://codereview.chromium.org/3028047/diff/8001/9005
File testing/gtest_mac_unittest.mm (right):

http://codereview.chromium.org/3028047/diff/8001/9005#newcode33
testing/gtest_mac_unittest.mm:33: EXPECT_NE(n1, n2);
Is this a valid assumption?

[Scott Hess - ex-Googler, 2010-08-10 00:00:33]

drive-by commenting.

http://codereview.chromium.org/3028047/diff/8001/9004
File testing/gtest_mac.mm (right):

http://codereview.chromium.org/3028047/diff/8001/9004#newcode23
testing/gtest_mac.mm:23: id<NSObject> actual) {
Suggest you add something like:

  if (!expected && !actual)
    return AssertionSuccess();
  else if (!expected)
    return EqFailure(expected_expr, actual_expr, "<nil>", String(...), false);
  else if (!actual)
    return EqFailure(expected_expr, actual_expr, String(...), "<nil>", false);

Purpose is two-fold, both nil should be treated as eq, and provide a more useful
diagnostic otherwise.  Hmm, and -isEqual:nil might be poor.

http://codereview.chromium.org/3028047/diff/8001/9004#newcode40
testing/gtest_mac.mm:40: if (![expected isEqual:actual]) {
This isn't right if !expected && !actual.  And likely similar reasoning to above
for better diagnostic output.