Create ChromeEarlGrey waitForWebViewContainingText.

ios/chrome/test/earl_grey/chrome_earl_grey.h

Index: ios/chrome/test/earl_grey/chrome_earl_grey.h
diff --git a/ios/chrome/test/earl_grey/chrome_earl_grey.h b/ios/chrome/test/earl_grey/chrome_earl_grey.h
index 4eab5b9679826d4ad6e2fb3b9c74e080b1b32590..6d284974555e170cb5c6ef8feceaf418d59a6e3f 100644
--- a/ios/chrome/test/earl_grey/chrome_earl_grey.h
+++ b/ios/chrome/test/earl_grey/chrome_earl_grey.h
@@ -79,6 +79,10 @@ id ExecuteJavaScript(NSString* javascript,
 // 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_