Create ChromeEarlGrey waitForWebViewContainingText.

ios/chrome/test/earl_grey/chrome_earl_grey.h

 // Copyright 2016 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 IOS_CHROME_TEST_EARL_GREY_CHROME_EARL_GREY_H_
 #define IOS_CHROME_TEST_EARL_GREY_CHROME_EARL_GREY_H_
 
 #import <EarlGrey/EarlGrey.h>
 
 #include "url/gurl.h"
@@ skipping 61 matching lines @@
 + (void)waitForStaticHTMLViewContainingText:(NSString*)text;
 
 // Waits for there to be no static html view, or a static html view that does
 // not contain |text|. If the condition is not met within a timeout, a
 // GREYAssert is induced.
 + (void)waitForStaticHTMLViewNotContainingText:(NSString*)text;
 
 // Waits for a Chrome error page. If it is not found within a timeout, a
 // GREYAssert is induced.
 + (void)waitForErrorPage;
+
+// Waits for the current web view to contain |text|. If the condition is not met
+// within a timeout, a GREYAssert is induced.
++ (void)waitForWebViewContainingText:(NSString*)text;

[Eugene But (OOO till 7-30), 2017/04/21 18:49:21]

Is there a reason why this takes NSString and not std::string? I looked at
callers and they either have std::string/char[] (which they have to convert) or
a literal.

NSString* arguments forces multiple callers to use base::SysUTF8ToNSString which
makes code less readable.

[baxley, 2017/04/21 20:09:01]

I went back and forth on this. All the methods in this file are Obj-C, and take
NSString, so I opted for consistency with the APIs here. A handful of tests had
to do a decent amount of conversions, but a lot of tests were negligibly
affected. Some of the simple ones fit a little better with NSString, but as you
pointed out these are mostly dealing with literals.

If you feel strongly that the tests deal in string, and have one API in
ChromeEarlGrey that takes string amongst others that take NSString, I'm happy to
make the change.

[Eugene But (OOO till 7-30), 2017/04/21 21:37:45]

|loadURL:| takes GURL, instead of NSURL, so using C++ objects does not seem to
be a big deal. I don't want to make you change bunch of code, but I think it is
better to optimize API for callers, even if it makes it inconsistent. Also I
looked at other API that take NSString* and look like they also could take
std::string instead (clients pass either literal or have to convert std::string
to NSString*). Thoughts?

[baxley, 2017/04/21 22:41:58]

I'll look at it a little more and think about it. When I first looked, neither
looked great. I just want to think about it before spending time to do it, and
realizing it may not be much better.

 @end
 
 #endif  // IOS_CHROME_TEST_EARL_GREY_CHROME_EARL_GREY_H_