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

chrome/browser/ui/test/test_browser_dialog.h

Index: chrome/browser/ui/test/test_browser_dialog.h
diff --git a/chrome/browser/ui/test/test_browser_dialog.h b/chrome/browser/ui/test/test_browser_dialog.h
new file mode 100644
index 0000000000000000000000000000000000000000..b7483c78a18edfec9b14e6f58e0634e745fdf98b
--- /dev/null
+++ b/chrome/browser/ui/test/test_browser_dialog.h
@@ -0,0 +1,120 @@
+// 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 CHROME_BROWSER_UI_TEST_TEST_BROWSER_DIALOG_H_
+#define CHROME_BROWSER_UI_TEST_TEST_BROWSER_DIALOG_H_
+
+#include <string>
+#include <vector>
+
+#include "chrome/browser/ui/browser_window.h"
+#include "chrome/test/base/in_process_browser_test.h"
+#include "testing/gtest/include/gtest/gtest.h"
+#include "ui/gfx/native_widget_types.h"
+
+// TEST_BROWSER_DIALOG provides a way to register an InProcessBrowserTest
+// testing harness with a framework that collects the set of all Chrome browser
+// dialogs available, and provides a way to invoke them "interactively", in a
+// consistent way. This allows screenshots to be generated easily, with the same
+// test data, to assist with UI review. It also provides a registry of dialogs
+// so they can be systematically checked for subtle changes and regressions.
+//
+// To use TEST_BROWSER_DIALOG, a test harness should inherit from
+// DialogBrowserTest rather than InProcessBrowserTest. If the dialog under test
+// has only a single mode of operation, the only other requirement on the test
+// harness is an override:
+//
+// class FooDialogTest : public DialogBrowserTest {
+//  public:
+//   ..
+//   // DialogBrowserTest:
+//   void ShowDialog(int index) override {
+//     /* Show dialog attached to browser() and leave it open. */
+//   }
+//   ..
+// };
+//
+// then in the foo_dialog_browsertest.cc, define:
+//
+//   TEST_BROWSER_DIALOG(FooDialogTest);
+//
+// This adds a test case "FooDialogTest.InvokeDefault", and registers with the
+// dialog testing framework. The dialog is shown and immediately closed (the
+// test harness does not need to close it). The "InvokeDefault" test case is run
+// as part of the regular test suite.
+//
+// To get a list of all available dialogs, run the `TestBrowserDialog.Invoke`
+// test case without other arguments. I.e.
+//
+//   browser_tests --gtest_filter=TestBrowserDialog.Invoke
+//
+// Dialogs listed can be shown interactively using the --dialog argument. E.g.
+//
+//   browser_tests --gtest_filter=TestBrowserDialog.Invoke --interactive \
+//       --dialog=FooDialogTest.Default
+//
+// Here the name "Default" is provided by the default implementation of a
+// NameProvider() static method. A test harness can invoke multiple styles by
+// declaring its own NameProvider that returns a vector of strings. E.g.
+//
+//   // static
+//   std::vector<std::string> FooDialogTest::NameProvider() {
+//     return {"Expired", "Valid"};
+//   }
+//
+// This registers multiple dialogs for `TestBrowserDialog.Invoke`. The |index|
+// given to the ShowDialog() override will correspond to the name provided via
+// the --dialog= switch.
+
+#define TEST_BROWSER_DIALOG(Harness)                                   \
+  int Harness##_register_names =                                       \
+      TestDialogInterface::Register(#Harness, &Harness::NameProvider); \
+  IN_PROC_BROWSER_TEST_F(Harness, InvokeDefault) {                     \
+    TestBrowserDialogRun(this, Harness::NameProvider());               \
+  }
+
+class TestDialogInterface {
+ public:
+  using NameProviderFunction = std::vector<std::string>();
+
+  // Provides a single name, "Default". Provide a "static" override of this to
+  // register multiple dialog styles with the dialog testing framework.
+  static NameProviderFunction NameProvider;
+
+  // Show the dialog corresponding to |index| of the names supplied by
+  // NameProvider().
+  virtual void ShowDialog(int index) = 0;
+
+  // The window that owns the dialogs. Used to find where the dialog appears.
+  virtual gfx::NativeWindow DialogParent() = 0;
+
+  // Called by the static initializer to register names. Only the
+  // TEST_BROWSER_DIALOG macro calls this.
+  static int Register(const char* harness, NameProviderFunction* name_provider);
+
+  // Called by the generated test case to invoke the dialog(s).
+  static void TestBrowserDialogRun(
+      TestDialogInterface* harness,
+      const std::vector<std::string>& available_cases);
+};
+
+// Helper to mix in a TestDialogInterface to an existing test harness. |Base|
+// must be a descendant of InProcessBrowserTest.
+template <class Base>
+class SupportsTestDialog : public Base, public TestDialogInterface {
+ public:
+  SupportsTestDialog() {}
+
+  // TestDialogInterface:
+  gfx::NativeWindow DialogParent() override {
+    return this->browser()->window()->GetNativeWindow();
+  }
+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(SupportsTestDialog);
+};
+
+using DialogBrowserTest = SupportsTestDialog<InProcessBrowserTest>;

[Paweł Hajdan Jr., 2016/12/16 20:14:29]

nit: Just checking: is "using" allowed in headers? I might not be up-to-date
with some style guide changes. Feel free to just point me to some notes about
it.

[Peter Kasting, 2016/12/17 03:53:29]

Yes, this use of "using" is as a replacement for "typedef".  It is not the same
as a "using declaration".  The relevant section of the style guide is
http://google.github.io/styleguide/cppguide.html#Aliases .

+
+#endif  // CHROME_BROWSER_UI_TEST_TEST_BROWSER_DIALOG_H_