Re: Testing Pointer Lock
Thanks Tobie. Vincent - I recommend you forward your original message directly to public-test-in...@w3.org (FYI, the Web-driver folks also use W3C's #testing channel). I don't think any of WebApps' tests currently use Web-driver so there could be a bit of learning curve here but it's likely other specs will have similar requirements (f.ex. gamepad, screen orientation, fullscreen?) . -AB On 10/3/13 9:18 PM, ext Tobie Langel 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 sch...@google.com (mailto:sch...@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-in...@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
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 to...@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 sch...@google.com(mailto: sch...@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-in...@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
Testing Pointer Lock
Pointer lock is tricky to automate tests for. Consider some examples: - Upon lock, no pointer should be visible. - A user gesture is required to lock when not in fullscreen. - Transitioning to fullscreen and pointer lock then exiting fullscreen should maintain pointer lock. (User gesture required to enter fullscreen) - While locked, moving the mouse indefinitely in any direction must continue to provide non zero movementX/Y values. 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. I appreciate any best practice suggestions, or pointers to other specifications with similar challenges. So far I see geolocation tests provide manual instructions.
Re: Testing Pointer Lock
On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib sch...@google.com wrote: Pointer lock is tricky to automate tests for. Consider some examples: - Upon lock, no pointer should be visible. - A user gesture is required to lock when not in fullscreen. - Transitioning to fullscreen and pointer lock then exiting fullscreen should maintain pointer lock. (User gesture required to enter fullscreen) - While locked, moving the mouse indefinitely in any direction must continue to provide non zero movementX/Y values. 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. I appreciate any best practice suggestions, or pointers to other specifications with similar challenges. So far I see geolocation tests provide manual instructions. Longdesc also has manual tests. The ones at http://github.com/chaals/longdesc-tests are looking like they will be accepted as actual tests. There is *1* automated test, which I haven't tried to put it into testharness yet. -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Testing Pointer Lock
On Thursday, October 3, 2013 at 11:04 PM, Charles McCathie Nevile wrote: On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib sch...@google.com (mailto:sch...@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-in...@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
