Add a TestBrowserDialog helper class for testing browser dialogs in a consistent way.

chrome/browser/ui/test/browser_dialog_browsertest.cc

Index: chrome/browser/ui/test/browser_dialog_browsertest.cc
diff --git a/chrome/browser/ui/test/browser_dialog_browsertest.cc b/chrome/browser/ui/test/browser_dialog_browsertest.cc
new file mode 100644
index 0000000000000000000000000000000000000000..2c769d3b28b6081501ef2d977d440cf41e9a9cd4
--- /dev/null
+++ b/chrome/browser/ui/test/browser_dialog_browsertest.cc
@@ -0,0 +1,74 @@
+// 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.
+
+#include "base/command_line.h"
+#include "base/process/launch.h"
+#include "base/test/launcher/test_launcher.h"
+#include "base/test/test_switches.h"
+#include "base/test/test_timeouts.h"
+#include "chrome/browser/ui/test/test_browser_dialog.h"
+#include "testing/gtest/include/gtest/gtest.h"
+#include "ui/compositor/compositor_switches.h"
+
+namespace {
+
+// Switch for BrowserDialogTest.Invoke to spawn a subprocess testing the
+// provided argument under a consistent setup.
+constexpr const char kDialogSwitch[] = "dialog";
+
+// Pattern to search in test names that indicate support for dialog testing.
+constexpr const char kDialogPattern[] = "InvokeDialog_";
+
+}  // namespace
+
+// Adds a browser_test entry point into the dialog testing framework. Without a
+// --dialog specified, just lists the available dialogs and exits.
+TEST(BrowserDialogTest, Invoke) {
+  const base::CommandLine& invoker = *base::CommandLine::ForCurrentProcess();
+  const std::string dialog_name = invoker.GetSwitchValueASCII(kDialogSwitch);
+
+  std::set<std::string> dialog_cases;
+  const testing::UnitTest* unit_test = testing::UnitTest::GetInstance();
+  for (int i = 0; i < unit_test->total_test_case_count(); ++i) {
+    const testing::TestCase* test_case = unit_test->GetTestCase(i);
+    for (int j = 0; j < test_case->total_test_count(); ++j) {
+      const char* name = test_case->GetTestInfo(j)->name();
+      if (strstr(name, kDialogPattern))
+        dialog_cases.insert(test_case->name() + std::string(".") + name);
+    }
+  }
+
+  if (dialog_name.empty()) {
+    std::string case_list;
+    for (const std::string& name : dialog_cases)
+      case_list += "\t" + name + "\n";
+    VLOG(0) << "\nPass one of the following after --" << kDialogSwitch << "=\n"
+            << case_list;
+    return;
+  }
+
+  auto it = dialog_cases.find(dialog_name);
+  ASSERT_NE(it, dialog_cases.end()) << "Dialog '" << dialog_name
+                                    << "' not found.";
+
+  base::CommandLine command(invoker);
+
+  // Replace TestBrowserDialog.Invoke with |dialog_name|.
+  command.AppendSwitchASCII(base::kGTestFilterFlag, dialog_name);
+
+  base::LaunchOptions options;
+
+  // Disable timeouts and generate screen output if --interactive was specified.
+  if (command.HasSwitch(internal::kInteractiveSwitch)) {
+    command.AppendSwitchASCII(switches::kUiTestActionMaxTimeout,
+                              TestTimeouts::kNoTimeoutSwitchValue);
+    command.AppendSwitchASCII(switches::kTestLauncherTimeout,
+                              TestTimeouts::kNoTimeoutSwitchValue);
+    command.AppendSwitch(switches::kEnablePixelOutputInTests);
+  } else {
+    options.wait = true;
+  }
+
+  base::LaunchProcess(command, options);

[Paweł Hajdan Jr., 2016/12/20 16:27:15]

Are we launching all subprocesses under one test?

That one test (BrowserDialogTest.Invoke) will still be subject to test launcher
timeouts. As more test cases are added, I don't think it'll be sustainable.

Have you considered parametrizing the test? See
https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuid...
for a possible way to do that.

[tapted, 2016/12/20 23:34:47]

I think this falls under the 'Future Work' section of the design doc (link:
https://goo.gl/ynxx1l for newcomers).

In this CL (and without the --interactive argument), BrowserDialogTest.Invoke
merely lists the available dialogs and exits. To pursue the "automated test
suite leveraging and iterating over ShowDialog()" future work item - you are
quite right that we will need something more intelligent here. Some kind of
sharding is likely.

A possible approach would be for TestBrowserDialog::RunDialog() to iterate over
the `DialogAction` enum for a single dialog, rather than have
BrowserDialogTest.Invoke iterate over all the dialog styles. See patchset 8
(link:
https://codereview.chromium.org/2532793002/diff/160001/chrome/browser/ui/test...)
for what I had in mind for the other enum values for `DialogAction`. I think
this iteration will be able to run within the default timeouts.

The subprocess can then remain just for the `--interactive, --dialog=Foo` mode
(e.g. taking screenshots). Bots should never launch the subprocess.

+}