Makes MaterialDesignController initialization explicit

content/public/test/browser_test_base.cc

Index: content/public/test/browser_test_base.cc
diff --git a/content/public/test/browser_test_base.cc b/content/public/test/browser_test_base.cc
index 7b7513aabb472ba4d9075127381132ea4323aed3..d6bb6671bac970b37fcdf5b2bd5982d28e4f0fc7 100644
--- a/content/public/test/browser_test_base.cc
+++ b/content/public/test/browser_test_base.cc
@@ -30,6 +30,7 @@
 #include "net/base/network_interfaces.h"
 #include "net/dns/mock_host_resolver.h"
 #include "net/test/embedded_test_server/embedded_test_server.h"
+#include "ui/base/test/material_design_controller_test_api.h"
 #include "ui/compositor/compositor_switches.h"
 #include "ui/gl/gl_implementation.h"
 #include "ui/gl/gl_switches.h"
@@ -179,6 +180,10 @@ BrowserTestBase::~BrowserTestBase() {
 
 void BrowserTestBase::SetUp() {
   set_up_called_ = true;
+  // ContentTestSuiteBase might have already initialized
+  // MaterialDesignController in browser_tests suite.
+  // Uninitialize here to let the browser process do it.
+  ui::test::MaterialDesignControllerTestAPI::UninitializeMode();

[sky, 2016/04/11 15:32:40]

Is it possible to supply a flag to ContentTestSuiteBase so you don't need the
uninitialize here?

[varkha, 2016/04/11 19:30:58]

Not sure how this would be possible.
The call stack I am dealing here is doing something like this:
base::TestSuite::Run {
  (first calls:)
  -> TestSuite::Initialize() -> MDC::Initialize()

  (and then, still in TestSuite::Run())
  -> testing::UnitTest::Run()
   -> UnitTestImpl::RunAllTests()
    -> ... (browser tests init)
     -> content::BrowserTestBase::SetUp()
      -> ... (BrowserMain initalization)
       -> ChromeBrowserMainParts::PreCreateThreadsImpl()
        -> MDC::Initialize()
That second call to MDC::Init we need in a production browser code. The first
call is in ContentTestSuiteBase and is necessary to make a lot of tests happy
that need to load resource packs first.

More tests have something similar - they load resource packs (and so we need to
kick MDC) and then proceed to use something like a child of ViewsTestBase or
AuraTestBase (which can also be run on their own in aura_unittests or
views_unittests and so need their own MDC::Init call).

I was trying to come up with the fewest number of (necessary and temporary evil)
calls to MaterialDesignControllerTestAPI::UninitializeMode() that would still
get all the bots happy.

 
   base::CommandLine* command_line = base::CommandLine::ForCurrentProcess();