Switch PPAPITests to run in browser_tests instead of ui_tests. The former is sharded and so tests run in parallel. Before this they were taking 17 minutes on the trybot. Now they take about a minute.

Another benefit is we can replace the sleeps with messages, so hopefully this makes the test faster/less flakier.

BUG=115595
Review URL: https://chromiumcodereview.appspot.com/9646027

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@126019 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 13 insertions, 18 deletions

diff --git a/ppapi/tests/testing_instance.h b/ppapi/tests/testing_instance.h
index 7b05174..55c7e3d 100644
--- a/ppapi/tests/testing_instance.h
+++ b/ppapi/tests/testing_instance.h
@@ -19,20 +19,19 @@ class TestCase;
 
 // How signaling works:
 //
-// We want to signal to the Chrome UI test harness
+// We want to signal to the Chrome browser test harness
 // (chrome/test/ui/ppapi_uitest.cc) that we're making progress and when we're
-// done. The easiest thing in the UI test infrastructure is to wait for a
-// cookie to become nonempty. We don't want to have a big wait for all tests in
-// a TestCase since they can take a while and it might timeout.  So we set a
-// series of cookies with an incrementing number in the name.
+// done. This is done using the DOM controlller. The browser test waits for a
+// message from it. We don't want to have a big wait for all tests in a TestCase
+// since they can take a while and it might timeout.  So we send it pings
+// between each test to tell it that we're still running tests and aren't stuck.
 //
-// If the value of the cookie is "..." then that tells the test runner that
-// the test is progressing. It then waits for the next numbered cookie until
-// it either times out or the value is something other than "...". In this
-// case, the value will be either "PASS" or "FAIL [optional message]"
-// corresponding to the outcome of the entire test case. Timeout will be
-// treated just like a failure of the entire test case and the test will be
-// terminated.
+// If the value of the message is "..." then that tells the test runner that
+// the test is progressing. It then waits for the next message until it either
+// times out or the value is something other than "...". In this case, the value
+// will be either "PASS" or "FAIL [optional message]" corresponding to the
+// outcome of the entire test case. Timeout will be treated just like a failure
+// of the entire test case and the test will be terminated.
 //
 // In trusted builds, we use InstancePrivate and allow tests that use
 // synchronous scripting. NaCl does not support synchronous scripting.
@@ -89,6 +88,8 @@ pp::InstancePrivate {
   // Sets the given cookie in the current document.
   void SetCookie(const std::string& name, const std::string& value);
 
+  void ReportProgress(const std::string& progress_value);
+
  private:
   void ExecuteTests(int32_t unused);
 
@@ -115,8 +116,6 @@ pp::InstancePrivate {
   // Appends the given HTML string to the console in the document.
   void LogHTML(const std::string& html);
 
-  void ReportProgress(const std::string& progress_value);
-
   pp::CompletionCallbackFactory<TestingInstance> callback_factory_;
 
   // Owning pointer to the current test case. Valid after Init has been called.
@@ -126,10 +125,6 @@ pp::InstancePrivate {
   // runs only tests whose name contains test_filter_ as a substring.
   std::string test_filter_;
 
-  // The current step we're on starting at 0. This is incremented every time we
-  // report progress via a cookie. See comment above the class.
-  int progress_cookie_number_;
-
   // Set once the tests are run so we know not to re-run when the view is sized.
   bool executed_tests_;