W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2012

Re: [battery] Feedback on battery tests

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Fri, 23 Nov 2012 14:59:40 +0200
Cc: <public-device-apis@w3.org>
Message-Id: <CDE2427C-E438-48CC-99A4-656A44ED98FF@nokia.com>
To: ext Dominique Hazael-Massieux <dom@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.

Received on Friday, 23 November 2012 12:59:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:56 UTC