- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Thu, 19 Feb 2015 10:16:59 +0000
- To: "Zhang, Zhiqiang" <zhiqiang.zhang@intel.com>
- CC: Device APIs Working Group <public-device-apis@w3.org>
Hi Zhiqiang, All, > On 13 Feb 2015, at 09:15, Zhang, Zhiqiang <zhiqiang.zhang@intel.com> wrote: > > The battery test suite has been updated to reflect the latest spec at > > https://github.com/w3c/web-platform-tests/issues?q=label%3Abattery-status+is%3Aclosed Zhiqiang - much thanks for the timely and complete updates to the test suite! > You can try again the updated tests at > > http://www.w3c-test.org/battery-status/ Here are my updated test results with Chrome 40.0.2214.111 (64-bit) on OS X. * [PASS] battery-charging-manual.html * [N/A] battery-created-manual.html Not tested, since "this test is only useful on devices that expose the BatteryManager interface, but lack a backend implementation." * [PASS] battery-discharging-manual.html * [PASS] battery-full-manual.html * [FAIL] battery-interface-idlharness.html 6 Pass, 26 Fail * [FAIL] battery-interface.html 35 Pass, 16 Fail I suspect at least some of the failed tests in battery-interface-idlharness.html and battery-interface.html are related to the fact Chrome is not fully WebIDL spec conformant yet, see: http://crbug.com/43394 Zhiqiang - are you able to track the root cause of these failures? I'd guess many tests that use idlharness.js would suffer from the same failures, if this is (partially) related to bug 43394 as I suspect without diving deep. * [FAIL] battery-plugging-in-manual.html 3 Pass, 1 Fail - 1 test fails with the message: assert_equals: The value of the dischargingTime attribute must be set to Infinity. expected Infinity but got 10380 This seem to be a bug in the implementation, that is in conflict with the following assertion in the CR spec: [[ The dischargingTime attribute must be set to the value positive Infinity, if the battery is charging http://www.w3.org/TR/2014/CR-battery-status-20141209/#widl-BatteryManager-dischargingTime ]] Zhiqiang - correct? If my hunch is correct, we should file a bug against the implementation and find someone to fix it. * [PASS] battery-promise.html * [PASS] battery-unplugging-manual.html > ... and check my comment inline for your feedback. [...] >> From: Kostiainen, Anssi [...] >> * battery-charging-manual.html >> * battery-discharging-manual.html >> >> I'm wondering if the timeout should be increased in these tests since e.g. in >> battery-discharging-manual.html I got the following error message I suspect >> is due to premature timeout: > > This has nothing to do with timeout. The tests are buggy and fixed at > > https://github.com/w3c/web-platform-tests/commit/8978c3804af01b01bef6e3ea6ecb052bf90c7d8d The fixes looks great, thanks! [...] >> * battery-interface-idlharness.html >> * battery-interface.html >> >> These tests are per the old spec, to be updated. If we can get good enough >> coverage with the idlharness only, we can actually drop battery- >> interface.html and update the battery-interface-idlharness.html per the >> latest CR. > > At current being, still keep them both. OK. See my comments above re the failed tests. >> * battery-promise.html >> >> Pass. >> >> * battery-plugged-in-manual.html >> * battery-unplugged-manual.html >> >> To be updated to the latest CR. > > Updated. And the tests have been renamed to better reflect the test precondition and user interaction: Perfect. > * battery-plugging-in-manual.html > * battery-unplugging-manual.html > > Again, all feedback is welcome. Related to test suite itself, I only have minor editorial nit: * s/navigator.battery/BatteryManager/g to update the descriptions of some of the tests. A reasonable plan forward might be to: * investigate the reasons for test failures on known implementations * address the assumed implementation bugs * assess the impact on the spec progress: a precondition to exit CR would be to get two implementations, for example, if the Chrome bugs (http://crbug.com/43394, others?) are fixed, and Mozilla updates its implementation (https://bugzil.la/1047119) Thanks, -Anssi
Received on Thursday, 19 February 2015 10:18:37 UTC