Add Settings bluetooth page test

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

Index: chrome/test/data/webui/settings/bluetooth_page_browsertest.js
diff --git a/chrome/test/data/webui/settings/bluetooth_page_browsertest.js b/chrome/test/data/webui/settings/bluetooth_page_browsertest.js
new file mode 100644
index 0000000000000000000000000000000000000000..b744017ab2a1cf32d0084db53fffc88a41461093
--- /dev/null
+++ b/chrome/test/data/webui/settings/bluetooth_page_browsertest.js
@@ -0,0 +1,62 @@
+// 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 Suite of tests for settings-bluetooth-page. */
+
+GEN_INCLUDE(['settings_page_browsertest.js']);
+
+/**
+ * @constructor
+ * @extends {SettingsPageBrowserTest}
+*/
+function SettingsBluetoothPageBrowserTest() {}
+
+SettingsBluetoothPageBrowserTest.prototype = {
+  __proto__: SettingsPageBrowserTest.prototype,
+};
+
+// Runs bluetooth tests.
+TEST_F('SettingsBluetoothPageBrowserTest', 'Bluetooth', function() {
+  // Assign |self| to |this| instead of binding since 'this' in suite()
+  // and test() will be a Mocha 'Suite' or 'Test' instance.
+  var self = this;
+
+  var enabled_ = false;

[dpapad, 2015/11/20 18:49:43]

Nit: Local vars don't need underscore at the end (usually used to indicate a
private member var).

[stevenjb, 2015/11/23 18:43:07]

Done.

+
+  chrome.bluetooth.getAdapterState = function(callback) {

[dschuyler, 2015/11/20 22:22:36]

Is it useful to add a short timeout/delay to simulate the async call?
(I've found that useful in some C++ tests, but maybe JS is different enough that
a simulated delay wouldn't be necessary)?

[stevenjb, 2015/11/23 18:43:07]

We don't need an actual delay (and should generally avoid them if possible in
tests), but deferring this with setTimeut(callback(...)) does make sense.
Done.

+    callback({
+      address: '00:11:22:33:44:55:66',
+      name: 'Fake Adapter',
+      powered: enabled_,
+      available: true,
+      discovering: false
+    });
+  };
+
+  chrome.bluetoothPrivate.setAdapterState = function(state, callback) {
+    enabled_ = state.powered;
+    callback();
+  };
+
+  suite('SettingsBluetoothPage', function() {
+    test('enable', function() {
+      var bluetoothSection =
+          self.getSection(self.getPage('advanced'), 'bluetooth');
+      assertTrue(!!bluetoothSection);
+      var bluetooth =
+          bluetoothSection.querySelector('settings-bluetooth-page');
+      assertTrue(!!bluetooth);
+      var enable = bluetooth.$.enableBluetooth;
+      assertTrue(!!enable);
+      assertFalse(enabled_);
+      expectFalse(enable.checked);
+      MockInteractions.tap(enable);
+      expectTrue(enable.checked);

[dpapad, 2015/11/20 18:49:43]

What is the difference of expectTrue and assertTrue?

[stevenjb, 2015/11/20 18:55:03]

asset will fail and stop the test immediately. It is useful for things that
should never fail or would invalidate the rest of the test. Here, if
enable.checked is false, enabled_ might still be true which means that the
'changed' event and fake API is working but the toggle itself is somehow not (or
is getting toggled back).

+      expectTrue(enabled_);
+    });
+  });
+
+  // Run all registered tests.
+  mocha.run();
+});