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

ui/base/test/material_design_controller_test_api.h

Index: ui/base/test/material_design_controller_test_api.h
diff --git a/ui/base/test/material_design_controller_test_api.h b/ui/base/test/material_design_controller_test_api.h
index 3eb53a349f5585ad03e677b5e84478335a66b271..09cbc6748e256e21c75453afb33cbec6ff177281 100644
--- a/ui/base/test/material_design_controller_test_api.h
+++ b/ui/base/test/material_design_controller_test_api.h
@@ -19,12 +19,17 @@ class MaterialDesignControllerTestAPI {
   explicit MaterialDesignControllerTestAPI(MaterialDesignController::Mode mode);
   ~MaterialDesignControllerTestAPI();
 
+  // Force the given |value| for IsSecondaryUiMaterial() for the lifetime of the
+  // test API.
+  void SetSecondaryUiMaterial(bool value);

[Peter Kasting, 2016/12/15 08:12:29]

Nit: ...ForTesting()?

[tapted, 2016/12/16 04:21:54]

I tried this out, but it felt a bit too redundant to say `ui::test::FooTestApi
test_api; test_api.SetFooForTesting(..)`. I think `ForTesting` comes up more
often when a release-code header needs to declare a testing method (so that,
e.g., presubmits can complain if release-code tries to call it).

But when it's a member of a test API in a test-only header (and test namespace),
that requirement doesn't present itself. (even sounds a bit like we're testing
the TestAPI :).

[Peter Kasting, 2016/12/16 06:30:56]

Yes, I agree with you.  My brain was not processing that this was in XXXTestAPI.

+
   // Wrapper functions for MaterialDesignController internal functions.
   static void Uninitialize();
 
  private:
   const MaterialDesignController::Mode previous_mode_;
   const bool previous_initialized_;
+  const bool previous_include_secondary_ui_;
 
   DISALLOW_COPY_AND_ASSIGN(MaterialDesignControllerTestAPI);
 };