LayoutTests/bluetooth/requestDevice.html - Issue 1174843002: Add tests for RequestDeviceOptions and clean up.

Side by Side Diff: LayoutTests/bluetooth/requestDevice.html

Issue 1174843002: Add tests for RequestDeviceOptions and clean up. (Closed) Base URL: https://chromium.googlesource.com/chromium/blink.git@pinned

Patch Set: Sync Created 5 years, 6 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

OLD	NEW
1 <!DOCTYPE html>	1 <!DOCTYPE html>

2 <script src="../resources/testharness.js"></script>	2 <script src="../resources/testharness.js"></script>

3 <script src="../resources/testharness-helpers.js"></script>	3 <script src="../resources/testharness-helpers.js"></script>

4 <script src="../resources/testharnessreport.js"></script>	4 <script src="../resources/testharnessreport.js"></script>

5 <script src="bluetooth-helpers.js"></script>	5 <script src="bluetooth-helpers.js"></script>

6 <script>	6 <script>

7 test(function(t) { assert_exists(window, "testRunner"); t.done(); },	7 test(function(t) { assert_exists(window, "testRunner"); t.done(); },

8 "window.testRunner is required for the following tests.");	8 "window.testRunner is required for the following tests.");

9	9

10 sequential_promise_test(function() {	10 sequential_promise_test(function() {

(...skipping 20 matching lines...) Expand all Loading...
31 }, 'Reject with NotFoundError.');	31 }, 'Reject with NotFoundError.');

32	32

33 sequential_promise_test(function() {	33 sequential_promise_test(function() {

34 testRunner.setBluetoothMockDataSet('SingleEmptyDeviceAdapter');	34 testRunner.setBluetoothMockDataSet('SingleEmptyDeviceAdapter');

35 return navigator.bluetooth.requestDevice({	35 return navigator.bluetooth.requestDevice({

36 filters: [{services: [genericAccessServiceUuid]}]	36 filters: [{services: [genericAccessServiceUuid]}]

37 }).then(function(device) {	37 }).then(function(device) {

38 assert_equals(device.constructor.name, "BluetoothDevice");	38 assert_equals(device.constructor.name, "BluetoothDevice");

39 });	39 });

40 }, 'Mock will resolve.');	40 }, 'Mock will resolve.');

	41

	42 sequential_promise_test(function() {

	43 testRunner.setBluetoothMockDataSet('ScanFilterCheckingAdapter');

	44 return navigator.bluetooth.requestDevice({

	45 filters: [

	46 {services: [batteryServiceUuid]},

	47 {services: [glucoseServiceUuid, heartRateServiceUuid]}

	48 ],

	49 optionalServices: [genericAccessServiceUuid]

	50 }).catch(function(e) {
	scheib 2015/06/15 23:47:14 Would be nice to have a .then(/* verify something 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 dr Show quoted text On 2015/06/15 23:47:14, scheib wrote: > Would be nice to have a .then(/* verify something worked /, / assert_unreached > /) 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 d Show quoted text On 2015/06/16 01:31:33, Jeffrey Yasskin wrote: > On 2015/06/15 23:47:14, scheib wrote: > > Would be nice to have a .then(/* verify something worked /, / > assert_unreached > > /) > > With your suggestion on the browser side, I can drop the .catch entirely. Simply > getting a device back verifies that it worked. 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 ScanFilte Show quoted text On 2015/06/16 03:11:48, scheib wrote: > On 2015/06/16 01:31:33, Jeffrey Yasskin wrote: > > On 2015/06/15 23:47:14, scheib wrote: > > > Would be nice to have a .then(/* verify something worked /, / > > assert_unreached > > > */) > > > > With your suggestion on the browser side, I can drop the .catch entirely. > Simply > > getting a device back verifies that it worked. > > 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. 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.
	51 assert_equals(e.name, 'NotFoundError',

	52 'Started discovery with an unexpected set of UUIDs.');

	53 });

	54 }, 'Filters restrict the platform\'s Bluetooth scan.');

	55

	56 sequential_promise_test(function() {

	57 testRunner.setBluetoothMockDataSet('MultiDeviceAdapter');

	58 return Promise.all([

	59 navigator.bluetooth.requestDevice({

	60 filters: [{services: [glucoseServiceUuid]}]

	61 }).then(function(device) {

	62 assert_equals(device.name, "Glucose Device");

	63 }),

	64 navigator.bluetooth.requestDevice({

	65 filters: [{services: [heartRateServiceUuid]}]

	66 }).then(function(device) {

	67 assert_equals(device.name, "Heart Rate Device");

	68 }),

	69 ]);

	70 }, 'Filters determine the returned devices.');

	71
	scheib 2015/06/15 23:47:14 Hmm, more test ideas to consider: - Multiple devi 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? Show quoted text On 2015/06/15 23:47:14, scheib wrote: > Hmm, more test ideas to consider: > > - Multiple devices each match one of multiple filters. > e.g. filters: [{services: [glucoseServiceUuid]}, > {services: [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) 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? Show quoted text > - More filters exist than devices, but one is returned. > e.g. filters: [{services: [somethingNotFoundServiceUuid]}, > {services: [heartRateServiceUuid]}, > {services: [somethingNotFoundServiceUuid2]}] > (adapter has only heart rate device, it is returned) I've added this one, and a couple others. scheib 2015/06/16 03:11:48 Yes, not essential, but not a bad idea. Show quoted text On 2015/06/16 01:31:33, Jeffrey Yasskin wrote: > On 2015/06/15 23:47:14, scheib wrote: > > Hmm, more test ideas to consider: > > > > - Multiple devices each match one of multiple filters. > > e.g. filters: [{services: [glucoseServiceUuid]}, > > {services: [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) > > So these two are basically "doesn't crash" tests? Yes, not essential, but not a bad idea. Show quoted text > 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? 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. Show quoted text > > > - More filters exist than devices, but one is returned. > > e.g. filters: [{services: [somethingNotFoundServiceUuid]}, > > {services: [heartRateServiceUuid]}, > > {services: [somethingNotFoundServiceUuid2]}] > > (adapter has only heart rate device, it is returned) > > I've added this one, and a couple others. Jeffrey Yasskin 2015/06/16 17:18:08 Here's an issue for wiring up the dialog in a test Show quoted text On 2015/06/16 03:11:48, scheib wrote: > On 2015/06/16 01:31:33, Jeffrey Yasskin wrote: > > 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? > > 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. Here's an issue for wiring up the dialog in a testable way: https://crbug.com/500989.
41 </script>	72 </script>

OLD	NEW

« no previous file with comments | « LayoutTests/bluetooth/idl-BluetoothDevice.html ('k') | public/platform/modules/bluetooth/WebBluetooth.h » ('j') | no next file with comments »