Initialize BlueZ in app_shell on Linux

extensions/test/data/api_test/app_apis/runtest.js

Index: extensions/test/data/api_test/app_apis/runtest.js
diff --git a/extensions/test/data/api_test/app_apis/runtest.js b/extensions/test/data/api_test/app_apis/runtest.js
new file mode 100644
index 0000000000000000000000000000000000000000..e3e2416a6b05a5c9e7a22026c7a1a40e8f128edd
--- /dev/null
+++ b/extensions/test/data/api_test/app_apis/runtest.js
@@ -0,0 +1,44 @@
+// Copyright 2017 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 Basic tests of API functions in a real (non-mocked) shell to
+ * ensure they can be called from a particular client or environment.
+ * Tests that verify specific behaviors should be in their own API tests.
+ */
+
+// Tests chrome.bluetooth availability.
+function testBluetooth() {
+  chrome.test.assertTrue(
+    !!chrome.bluetooth, 'chrome.bluetooth should be available');

[michaelpg, 2017/04/14 22:54:43]

oops, will fix this indent

+
+  chrome.bluetooth.getAdapterState(chrome.test.callback());
+  chrome.bluetooth.getDevice(
+      'AB:CD:EF:01:23:45', chrome.test.callback(() => {}, 'Invalid device'));
+  chrome.bluetooth.getDevices(chrome.test.callback());
+
+  // TODO(michaelpg): Re-enable on Chrome OS after crbug.com/711484 is fixed.
+  if (!/CrOS/.test(navigator.userAgent)) {
+    var startDiscoveryCallback = chrome.test.callbackAdded();
+    chrome.bluetooth.startDiscovery(function() {
+      // Ignore errors.
+      chrome.runtime.lastError;
+      startDiscoveryCallback();
+    });
+
+    var stopDiscoveryCallback = chrome.test.callbackAdded();
+    chrome.bluetooth.stopDiscovery(function() {
+      // Ignore errors.
+      chrome.runtime.lastError;
+      stopDiscoveryCallback();
+    });
+  }
+}
+
+chrome.app.runtime.onLaunched.addListener(function() {
+  chrome.test.runTests([
+    testBluetooth,

[Devlin, 2017/04/14 01:43:44]

It's going to be hard to scale this. Is there any way we can iterate over APIs?
Or do we really need to have end-to-end tests of a method?

[michaelpg, 2017/04/14 03:52:58]

I'm not sure what "really" is modifying here...

"Do we *really* need end-to-end tests of a method?"

Yes, because without them we don't notice that they crash app_shell and/or
chrome.

"Do we really need *end-to-end* tests of a method?"

Yes, but that's not ready yet.
https://docs.google.com/document/d/12a1k9BT5-1FjLyNhUA9wKFgcO1rWsbuu0h7S-lrH7yQ

[Devlin, 2017/04/14 16:10:30]

It will be a losing battle to try and re-test every API in both appshell and
chrome.  I think longer term, we want to look into a way of testing both while
only writing a single test (which I think is what the doc is targeting,
ideally).  In the near-term, I guess I'm not sure if I see the benefit in trying
to write a thorough test for a single API in a one-off manner, rather than
either a) writing basic sanity checks or b) testing properties of the shell
system.

If we have to write one-offs for some things in the short term for other reasons
(if, for instance, bluetooth was a p1 api to get working on app shell and we
wanted to make sure nothing broke), that's fine, but then I wouldn't put it
under the guise of a generic "test all the apis!"-type test.

Does that make sense?

[michaelpg, 2017/04/14 22:54:43]

Yep! It should be as simple and automatic as possible.
Basic sanity checks are what I'm after in the near term. I don't see this test
as being thorough; it merely verifies that calling API functions does not throw
an error in JS or crash the process. We have real Bluetooth tests (that mostly
run in Chrome) which test the API implementation more thoroughly.
A crash when calling an API that's allowed on app_shell is a P1 bug. Tests that
identify (thus prevent) these bugs are also P1; LMK if you disagree and we can
discuss.

I'm fine with renaming this something like bluetooth_sanity_test if you like.

+    // TODO(michaelpg): Add more tests of basic API availability.
+  ]);
+});