Re: [presentation-api-tests] [presentation-api] Refine getAvailability() test (#4257)

Thanks @tomoyukilabs,

Reviewing this test made me read the `getAvailability` algorithm again, which triggered a few questions:
- https://github.com/w3c/presentation-api/issues/381 - Step 11 of getAvailability should not run "in parallel"
- https://github.com/w3c/presentation-api/issues/383 - Drop step 6 of getAvailability for consistency with start? (already fixed)
- https://github.com/w3c/presentation-api/issues/388 - Check on Presentation display availability in getAvailability can never be true

I would suggest to wait until these issues are resolved.

Other comments on the pull request:

1. I believe we should try to create automated tests as much as practical and reduce the scope of manual tests to a bare minimum. Most steps of the `getAvailability` algorithm should be testable without requiring any user interaction. Typically, I would take for granted that the starting point is an environment with at least one available presentation display and without restrictions (i.e. without "disabled" features). With that in mind, I think you can stick to an automated test here that eventually expects a `PresentationAvailability` object whose value is `true` (or a `NotSupportedError` exception).
2. Former step 6. has now moved to the monitoring algorithm. To test it, I would create a separate manual test that asks the user to disable monitoring and then calls `getAvailability`. That test should be marked as "optional" because user agents may not support disabling monitoring.
3. The first call to `getAvailability` will create the [presentation availability promise](http://w3c.github.io/presentation-api/#dfn-presentation-availability-promise). Calling `getAvailability` a second time will return that promise in step 2. In other words, the test should rather check that the returned `Promise` is the same in both cases, not that the `PresentationAvailability` instance is the same.


View on GitHub: https://github.com/w3c/web-platform-tests/pull/4257#issuecomment-264403341

Received on Friday, 2 December 2016 08:47:54 UTC