[MD settings] adding a test for Appearance settings

chrome/test/data/webui/settings/appearance_browsertest.js

+// Copyright 2015 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.
+
+/** @fileoverview Runs Polymer Appearance Settings elements. */
+
+// Polymer BrowserTest fixture.

[stevenjb, 2015/11/20 17:59:37]

Michael pointed out this comment is no longer accurate and should probably just
be removed.

[dschuyler, 2015/11/20 18:12:11]

Done.

+GEN_INCLUDE(['settings_page_browsertest.js']);
+
+/**
+ * Test Polymer Appearance Settings elements.
+ * @constructor
+ * @extends {PolymerTest}

[stevenjb, 2015/11/20 17:16:07]

@extends {SettingsPageBrowserTest}

[dschuyler, 2015/11/20 18:12:10]

Done.

+*/
+function AppearanceSettingsBrowserTest() {}
+
+AppearanceSettingsBrowserTest.prototype = {
+  __proto__: SettingsPageBrowserTest.prototype,
+
+  /** @return {string} */
+  appearancePage: function(selector) {
+    var section = this.getSection(this.getPage('basic'), 'appearance');
+    assertTrue(!!section);
+    var appearance = section.querySelector('settings-appearance-page');
+    assertTrue(!!appearance);
+    var result = appearance.$$(selector);
+    assertTrue(!!result);
+    return result;
+  },
+};
+
+TEST_F('AppearanceSettingsBrowserTest', 'uiTests', function() {
+  var self = this;
+  suite('AppearanceHandler', function() {
+    test('font settings', function() {
+      var fontSize = self.appearancePage(
+          '#defaultFontSize').$$('[class=iron-selected]');
+      assertEquals('Medium', fontSize.textContent);

[stevenjb, 2015/11/20 17:16:07]

nit: Personally I would just assertTrue(!!fontSize.textContent) to ensure that
it is defined and not empty so that the test doesn't break if we change the
default, but I'm fine with this as-is.

[michaelpg, 2015/11/20 17:23:41]

Dumb question: how do we know the prefs have loaded before this suite runs?

(How do Options tests ensure the fetchPrefs callback has been run?)

[stevenjb, 2015/11/20 17:59:37]

That's actually a good question. My guess is "they don't" but in practice we
have enough "deferred layers"?? (I'm not sure what the right JS terminology here
is) that any initial API callbacks will complete before we get here. i.e. The
API call will execute some C++ code that will (effectively) immediately insert
the JS callback to be run, and that will occur before the test has a chance to
run. (I don't actually have any idea how task scheduling works in JS).

Probably we ought to add a wrapper to mocha.run() in SettingsPageBrowserTest
that waits until Prefs has loaded before calling mocha.run() ?

[dschuyler, 2015/11/20 18:02:40]

I'm thinking that the prefs in this test will be replaced with the prefs fake. 
Since that will be JS, I think we will be able to control that more easily.

[michaelpg, 2015/11/20 18:07:44]

We don't need a wrapper per se. In settings_page_browsertest.js we can override
setUp (from testing.Test) and register a suite setup method that waits on the
prefs initialized promise:

/** @override */
setUp: function() {
  suiteSetup(function() {
    return CrSettingsPrefs.initialized;
  });
}

[dschuyler, 2015/11/20 18:12:11]

Cool.  I'd like to think about explicitly setting it to the medium font size
and then test that.  I'll put up a follow-up CL shortly and accept your
offer to keep this as-is for a day or so.

+    });
+
+    test('home button', function() {
+      var homeButton = self.appearancePage('#showHomeButton');
+      assertEquals('false', homeButton.getAttribute('aria-pressed'));
+    });
+  });
+  mocha.run();
+});