Re: Testing Pointer Lock

[BCC webapps, +test-infra]

Dear test infra, I've a pointer lock spec [1] which will be easiest to test
with automation such as WebDriver. I haven't used WebDriver, nor
testharness.js tests yet. As Tobie suggests below, I'd like to explore a
WebDriver option in the w3 context. This is a long term goal to have a
reasonable automatable test suite for pointer lock, I'll likely create a
few manual tests in the short term.

[1] http://www.w3.org/TR/pointerlock/
On Thu, Oct 3, 2013 at 6:18 PM, Tobie Langel <tobie@fb.com> wrote:

> On Thursday, October 3, 2013 at 11:04 PM, Charles McCathie Nevile wrote:
> > On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib <scheib@google.com(mailto:
> scheib@google.com)>
> > wrote:
> > > Pointer lock is tricky to automate tests for. Consider some examples:
> > > - Upon lock, no pointer should be visible.
> >
>
> That might be tested using a reftest[1].
> > > - A user gesture is required to lock when not in fullscreen.
> >
>
> That might be tested using a WebDriver test (we haven't agreed on a way to
> write or run those yet).
> >
>
>
> > > - Transitioning to fullscreen and pointer lock then exiting fullscreen
> > > should maintain pointer lock. (User gesture required to enter
> fullscreen)
> >
>
> This might also be feasible using WebDriver.
> > > - While locked, moving the mouse indefinitely in any direction must
> > > continue to provide non zero movementX/Y values.
> >
>
> That could be automated using WebDriver.
> > > I'm considering starting some pointer lock tests with testharness.js.
> The
> > > only solution I see is to provide instructions in many tests
> > > for manual actions and observations.
> >
>
> If there's interest on your side to explore the WebDriver-based option,
> I'm happy to start a discussion on how those tests should be written in the
> relevant channel (public-test-infra@w3.org), but that really depends on
> what your main goal with this effort is (move the spec along the REC track,
> or improve interop) and what your timeline's like. If you want to ship the
> spec quickly, going the manual route with testharness.js is probably your
> best option. You'll always be able to revisit later (you could even do both
> in parallel).
>
> --tobie
> ---
> [1]: http://testthewebforward.org/docs/reftests.html
>
>
>