Views: Add two disabled tests for invoking the CC unmask prompt dialog.

chrome/test/base/invoke_ui_browser_test.h

Index: chrome/test/base/invoke_ui_browser_test.h
diff --git a/chrome/test/base/invoke_ui_browser_test.h b/chrome/test/base/invoke_ui_browser_test.h
new file mode 100644
index 0000000000000000000000000000000000000000..e9f0d8f2d4df425614183479fe8504f862275f76
--- /dev/null
+++ b/chrome/test/base/invoke_ui_browser_test.h
@@ -0,0 +1,30 @@
+// 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_TEST_BASE_INVOKE_UI_BROWSER_TEST_H_
+#define CHROME_TEST_BASE_INVOKE_UI_BROWSER_TEST_H_
+
+namespace base {
+class CommandLine;
+}
+
+class InvokeUIBrowserTest {

[tapted, 2016/10/13 00:53:34]

I'd probably have this inherit from InProcessBrowserTest (we can also use
template inheritance if there are lots of tests that have a class already
inheriting from InProcessBrowserTest).

[Patti Lor, 2016/10/13 05:39:21]

Deleted this as per your other comments.

+
+ public:
+
+  // Call in SetCommandLineFlags(). Extends the default timeout to an
+  // "almost-infinite" number to avoid the UI closing unexpectedly.
+  void SetCommandLineFlags(base::CommandLine* command_line);

[tapted, 2016/10/13 00:53:34]

This this can override SetUpCommandLine and check for an existing flag like
"--show-ui", but we can ignore timeouts for now.

[Patti Lor, 2016/10/13 05:39:21]

Did you have something in mind for fixing the timeouts later on? Or is the plan
to just run the test with the timeout flags manually?

I'm also not really sure what you mean by the "--show-ui" thing?

[tapted, 2016/10/16 23:48:01]

I think we can make a python script to collect all the entrypoints for summoning
test dialogs and adding any extra flags we need. The goal of this CL is to
leverage the mock models/data used in tests so that we don't maintain those
separately (let's say something about that in the CL description).

If we later find that there's "stuff" that needs to be done via the
InProcessBrowserTest interfaces common to multiple test dialogs, we could check
for that in a shared base class and switch it on e.g. by looking for a new flag
we add like --show-ui, but we might not need it.

[Patti Lor, 2016/10/17 23:26:08]

Ah ok, I didn't realise you had a separate thing in mind to invoke all the UI
tests. Thanks for the clarification!

+
+  // Call before the default SetUp() method. On Mac, this will allow the process
+  // to get keyboard focus so that UI can be interacted with using the keyboard.
+  void BeforeSetUp();
+
+  // Call before the default TearDownOnMainThread(). Starts a runloop so
+  // that tests won't close on finishing.
+  void BeforeTearDownOnMainThread();
+
+};
+
+#endif  // CHROME_TEST_BASE_INVOKE_UI_BROWSER_TEST_H_