Re: [presentation-api-tests] Make PresentationConnection.onclose pass (#4222)

Could you clarify what test configuration you're using?

I have a Chromecast (running Google Cast v1.21.74816) for the receiving side. Google Chrome for Android (v54.0.2840.85) seems happy with the array constructor, picks up the Cast URL, regardless of its position in the array and shows my Chromecast in the list of devices available. Google Chrome for desktop (v54.0.2840.99m) and Chrome Canary (v57.0.2931.0) on Windows do not seem to support the array constructor at all. I get an empty list of devices (provided I force the source to be the controlling page as Chrome proposes to mirror the tab as a fallback) and a `NotFoundError` if I dismiss the dialog box. Changing the order of the URLs does not change anything. The only setting that makes my Chromecast appear is if `presentationUrls` is equal to the Cast URL.

In short, I get mixed results depending on what I use, but the order of URLs in the array and `castClientId` do not change anything for me. The `castClientId` is perhaps still needed, e.g. to bypass the cache. It just does not seem to be.

Regardless of these results, we want to create a test suite that can run across implementations of the Presentation API. Such tests should not contain proprietary code. Cast URLs are proprietary: the Presentation API does not define how a user agent is to handle a Cast URL and map it onto the address of the page to present. In theory, the test suite should not contain any reference to a Cast URL. It does in practice because that's the only available receiver right now, plus it allows to test the 2-UA mode. In an ideal world, we'd be able to get rid of Cast URLs soon.

Another problem we have to face today is the lack of implementations of the receiving side. `support/presentation.html` cannot load in the meantime, and some tests fail as a result.

> how can I make sure my test is correct if I write one which I cannot verify?

Well, you cannot! This is what makes writing tests so hard. The only things you can do are:

1. make sure your test code follows the spec algorithms
2. keep the test code as simple and readable as possible
3. get your code reviewed

Of course, you can change `common.js` in your local fork of the Web Platform Tests repository, but note that won't solve the bigger problem that there are no available implementations of the receiving side for the time being.

> Can I also test it with a true app?

By "true Cast app", I mean one that follows the [initialization steps](https://developers.google.com/cast/docs/custom_receiver#initialization--readiness) in the Custom Receiver Application Google Cast doc.
What do you call a "true app"? `support/presentation.html`?



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

Received on Monday, 28 November 2016 10:03:57 UTC