Initialize MaterialDesignController in NativeThemeMacTest

ui/native_theme/native_theme_mac_unittest.cc

Index: ui/native_theme/native_theme_mac_unittest.cc
diff --git a/ui/native_theme/native_theme_mac_unittest.cc b/ui/native_theme/native_theme_mac_unittest.cc
index c7c92d6d861b437a9e013f65d580bca6ee9f49e4..094a5ecc133ab195f13c20088ecf49cef6b78b3c 100644
--- a/ui/native_theme/native_theme_mac_unittest.cc
+++ b/ui/native_theme/native_theme_mac_unittest.cc
@@ -2,6 +2,7 @@
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
+#include "ui/base/material_design/material_design_controller.h"
 #include "ui/native_theme/native_theme_mac.h"
 
 #include "base/mac/mac_util.h"
@@ -13,6 +14,7 @@ namespace ui {
 // platforms Chrome supports, and that their colorspace and component count is
 // sane.
 TEST(NativeThemeMacTest, SystemColorsExist) {
+  MaterialDesignController::Initialize();

[Peter Kasting, 2016/07/06 20:57:07]

Wouldn't we need this in the next test too?

In fact in general wouldn't we potentially need this any time we access the Mac
theme APIs?

I think the solution for this probably needs to be more general.  You should
work with a Mac engineer like shrike@ or spqchan@ to figure out the right
solution.

[shrike, 2016/07/07 19:40:47]

I agree with pkasting@ that it should be more general. I believe that if you
create a test subclass, call MaterialDesignController::Initialize() from
Setup(), and then convert the TEST()s to TEST_F()s you should be all set. Check
out testing/gtest/include/gtest/gtest.h:348 for more info.

   NativeTheme* native_theme = NativeThemeMac::instance();
   ASSERT_TRUE(native_theme);
   for (int i = 0; i < NativeTheme::kColorId_NumColors; ++i) {