Add NSLogTestEventListener to support running tests on iOS 6 devices.

Add NSLogTestEventListener to support running tests on iOS 6 devices.

As of iOS 6, stdout is not written to the device's console log, so this CL adds
a TestEventListener that writes all teset output via NSLog.

BUG=None

[lliabraa, 2013-01-23 18:59:19]

@phajdan.jr for review (please let me know if there is someone more appropriate)
@jar for base/OWNERS

[jar (doing other things), 2013-01-23 19:13:32]

https://codereview.chromium.org/12047058/diff/1/base/test/nslog_test_event_li...
File base/test/nslog_test_event_listener.h (right):

https://codereview.chromium.org/12047058/diff/1/base/test/nslog_test_event_li...
base/test/nslog_test_event_listener.h:37: const testing::UnitTest& unit_test,
int iteration) OVERRIDE;
nit: one arg per line in declaration or definitions

Same issue on line 24

https://codereview.chromium.org/12047058/diff/1/base/test/nslog_test_event_li...
File base/test/nslog_test_event_listener.mm (right):

https://codereview.chromium.org/12047058/diff/1/base/test/nslog_test_event_li...
base/test/nslog_test_event_listener.mm:16: // copied from gtest.cc, but have
been refactored such that output goes to NSLog
...so why isn't this upstreamed to be a sibling of gtest.cc, or integrated
there?

[Paweł Hajdan Jr., 2013-01-24 01:41:53]

I think we shouldn't duplicate gtest. It's recipe for maintenance troubles and
small incompatibilities.

Could you get gtest changed in a way that would allow us to just substitute
printf for NSLog, or re-use more logic in some way?

[lliabraa, 2013-01-24 12:36:30]

I originally took the upstreaming approach but it is a significant refactoring
of core gtest code to support a small edge case. I agree there is potential for
drift, but we are already beholden to gtest maintaining their current output
formats for the log parsers on the bots to work.

Implementing our own TestEventListener seems a smaller risk than messing with
the gtest code and breaking the world. If you guys feel strongly that this
should be in gtest I can take another look.

https://chromiumcodereview.appspot.com/12047058/diff/1/base/test/nslog_test_e...
File base/test/nslog_test_event_listener.h (right):

https://chromiumcodereview.appspot.com/12047058/diff/1/base/test/nslog_test_e...
base/test/nslog_test_event_listener.h:37: const testing::UnitTest& unit_test,
int iteration) OVERRIDE;
On 2013/01/23 19:13:32, jar wrote:
> nit: one arg per line in declaration or definitions
> 
> Same issue on line 24

Done.

[jar (doing other things), 2013-01-24 17:10:20]

As I understand the patch, rather than getting fixes into stuff that is kindred
to third party (actually, gtest), you'd like to add to base with near-copies of
the file that are modified.

That is probably not a good reason for adding to base... so I'd really like to
see either an upstream effort, or worst case, landing in a place other than
base.

[Paweł Hajdan Jr., 2013-01-24 17:21:37]

On 2013/01/24 17:10:20, jar wrote:
> As I understand the patch, rather than getting fixes into stuff that is
kindred
> to third party (actually, gtest), you'd like to add to base with near-copies
of
> the file that are modified.
> 
> That is probably not a good reason for adding to base... so I'd really like to
> see either an upstream effort, or worst case, landing in a place other than
> base.

+1

We're probably not the only ones to hit this issue, so it seems worth it for
gtest to support it. I can help with convincing gtest maintainers if needed.

[lliabraa, 2013-01-24 17:29:47]

On 2013/01/24 17:21:37, Paweł Hajdan Jr. wrote:
> On 2013/01/24 17:10:20, jar wrote:
> > As I understand the patch, rather than getting fixes into stuff that is
> kindred
> > to third party (actually, gtest), you'd like to add to base with near-copies
> of
> > the file that are modified.
> > 
> > That is probably not a good reason for adding to base... so I'd really like
to
> > see either an upstream effort, or worst case, landing in a place other than
> > base.
> 
> +1
> 
> We're probably not the only ones to hit this issue, so it seems worth it for
> gtest to support it. I can help with convincing gtest maintainers if needed.

Okay..thanks for the input.