- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Fri, 23 Nov 2012 14:59:40 +0200
- To: ext Dominique Hazael-Massieux <dom@w3.org>
- Cc: <public-device-apis@w3.org>
Hi Dom, On 19.11.2012, at 12.16, ext Dominique Hazael-Massieux wrote: > As per my action item (ACTION-585), I have taken a look to the tests you > submitted for the battery API. Some resulting feedback: > * I think battery-interface.html would be better tested using > idlharness.js https://dvcs.w3.org/hg/resources/file/tip/idlharness.js > (see attached test as replacement); that being said, it may be that your > manually crafted test is more complete, in which case it might be worth > contributing a generic version of your additional tests to > idlharness.js :) I will have to look at the idlharness.js more closely and see if it's missing any tests that are in the manually crafted test (and vice versa). For now, I added your idlharness.js-based test to the test suite as an alternative to the manually crafted battery-interface test with a name battery-interface-idlharness. Thanks for your contribution :-) > * links to testharness.js should be not use an absolute URL > (http://www.w3c-test.org/resources/testharness.js) but rather the > relative URL h/resources/testharness.js (so that the test can be > integrated easily in other contexts) This is now fixed. > * most of the tests require human interaction, which the tests should > denoted with a flag: <meta name="flags" content="interact"> I added this flag to all manual tests (battery-charging, battery-discharging, battery-full, battery-plugged-in, battery-unplugged). > * when the timeout to run the test is long (e.g. in battery-charging, 5 > minutes), that should probably be told to the tester (who is otherwise > likely to estimate that the test is stuck) I added a countdown timer to those tests that take longer to run (battery-charging, battery-discharging, battery-plugged-in, battery-unplugged). I also split the prime computation into smaller chunks (i.e. let the process idle at certain intervals) to help keep the UI more responsive. The number crunching is still a heavy process and the UI thread updates itself sluggishly, despite the fact the task is run in a worker in smaller chunks. I will look into this more and try to improve the responsiveness. > * using alert() to guide the user seems a bit inappropriate, and > possibly not very accessible; could the instructions/steps be instead > integrated in the main page? This is a good point. I removed the alert()s from the tests battery-plugged-in and battery-unplugged and integrated corresponding interactive instructions to the main page itself. It should be more accessible now. > Thanks for your great work on this! Thanks for your excellent feedback and test contribution! Further feedback appreciated. -Anssi
Received on Friday, 23 November 2012 12:59:52 UTC