Add tests for RequestDeviceOptions and clean up.

LayoutTests/bluetooth/requestDevice.html

Index: LayoutTests/bluetooth/requestDevice.html
diff --git a/LayoutTests/bluetooth/requestDevice.html b/LayoutTests/bluetooth/requestDevice.html
index 932d985dde5c7bb6797c71d9e4fa636634f0a257..e07c4e441fcb11de7b0fc5e35e5c092ed377f1b8 100644
--- a/LayoutTests/bluetooth/requestDevice.html
+++ b/LayoutTests/bluetooth/requestDevice.html
@@ -38,4 +38,35 @@ sequential_promise_test(function() {
     assert_equals(device.constructor.name, "BluetoothDevice");
   });
 }, 'Mock will resolve.');
+
+sequential_promise_test(function() {
+  testRunner.setBluetoothMockDataSet('ScanFilterCheckingAdapter');
+  return navigator.bluetooth.requestDevice({
+    filters: [
+      {services: [batteryServiceUuid]},
+      {services: [glucoseServiceUuid, heartRateServiceUuid]}
+    ],
+    optionalServices: [genericAccessServiceUuid]
+  }).catch(function(e) {

[scheib, 2015/06/15 23:47:14]

Would be nice to have a .then(/* verify something worked */, /* assert_unreached
*/)

[Jeffrey Yasskin, 2015/06/16 01:31:33]

With your suggestion on the browser side, I can drop the .catch entirely. Simply
getting a device back verifies that it worked.

[scheib, 2015/06/16 03:11:48]

This one is nearly identical to "An extra filter doesn\'t prevent matching."
now, though it has optionalServices. Perhaps make them adjacent and name them
similarly or in another way to draw out the small diference. 

I think it's best as in the latter test to have the .then ...
assert_equals(device.name so that the expected result of the request is clear.

[Jeffrey Yasskin, 2015/06/16 17:18:08]

The important thing for this test is the ScanFilterCheckingAdapter, not anything
about the returned data. We're asserting that the platform is asked to scan with
the UUIDs in the filtered services, but not any UUIDs in the optional services.
So any similarity with a later test is probably more distracting than something
to draw out.

I can add a comment to that effect, so it's clearer to the next reader.

There isn't really any expected result of the request, since the work happens in
the mock adapter, not in this test. It's not even important to have the promise
reject when the test fails, since the EXPECT_CALL failing will cause the test to
fail.

+    assert_equals(e.name, 'NotFoundError',
+                  'Started discovery with an unexpected set of UUIDs.');
+  });
+}, 'Filters restrict the platform\'s Bluetooth scan.');
+
+sequential_promise_test(function() {
+  testRunner.setBluetoothMockDataSet('MultiDeviceAdapter');
+  return Promise.all([
+    navigator.bluetooth.requestDevice({
+      filters: [{services: [glucoseServiceUuid]}]
+    }).then(function(device) {
+      assert_equals(device.name, "Glucose Device");
+    }),
+    navigator.bluetooth.requestDevice({
+      filters: [{services: [heartRateServiceUuid]}]
+    }).then(function(device) {
+      assert_equals(device.name, "Heart Rate Device");
+    }),
+  ]);
+}, 'Filters determine the returned devices.');
+

[scheib, 2015/06/15 23:47:14]

Hmm, more test ideas to consider:

- Multiple devices each match one of multiple filters.
  e.g. filters: [{services: [glucoseServiceUuid,  
                             heartRateServiceUuid]}]
  (returns either one of them).

- Multiple devices match a single filter?
  e.g. filters: [{services: [glucoseServiceUuid]}]
  (adapter has 2+ glucose devices, any one of them returned)

- More filters exist than devices, but one is returned.
  e.g. filters: [{services: [somethingNotFoundServiceUuid,  
                             heartRateServiceUuid,
                             somethingNotFoundServiceUuid2]}]
  (adapter has only heart rate device, it is returned)

[Jeffrey Yasskin, 2015/06/16 01:31:33]

So these two are basically "doesn't crash" tests? I'd like to be able to assert
that we show _all_ of the devices in the dialog, but we don't have the dialog
hooked up yet, or a pathway to report which devices were shown. Maybe we should
wait on these until we have that?
I've added this one, and a couple others.

[scheib, 2015/06/16 03:11:48]

Yes, not essential, but not a bad idea.
OK, That's a good idea, though. Perhaps file an issue for ship blocking that we
bother to test the results of filters and what is shown? We'd have to plumb back
more info, and I'm unsure if we want to widen the testing API surface so much.
Later perhaps we'll see more nice to have testing API items and plan a design
for it.

[Jeffrey Yasskin, 2015/06/16 17:18:08]

Here's an issue for wiring up the dialog in a testable way:
https://crbug.com/500989.

 </script>