- From: Odin Hørthe Omdal <odinho@opera.com>
- Date: Mon, 09 Jan 2012 18:12:05 +0100
- To: "public-webapps-testsuite@w3.org" <public-webapps-testsuite@w3.org>, "Adrian Bateman" <adrianba@microsoft.com>
- Cc: "Israel Hilerio" <israelh@microsoft.com>, "Travis Leithead" <Travis.Leithead@microsoft.com>, "Brian Raymor" <Brian.Raymor@microsoft.com>, "Kris Krueger" <krisk@microsoft.com>
I've gone through some of the submitted tests for IndexedDB by Microsoft, and found some issues, here they are sorted by severeness: Issue 1 ------- This is a known issue, as it's already raised by Israel Hilerio from Microsoft: The tests are using the old IDBFactory.open() API. Issue 2 ------- The tests are abstracting away all error handling (to PassTest() and FailTest()) instead of using the testharness primitives directly. This means the only error message we will ever get is "assert_true: Expected true got false" which IMHO isn't very helpful. As far as I can see, there are two main patterns here, first one: try { <some code> } except { FailTest(); } I propose instead to do: t.step_func(function() { <some code> } As that will print the exception in the message field, allowing us to see relevant information about the exception. The other pattern: rqGet.onsuccess = function(event) { if (record.property == event.target.result.property) { PassTest(); } else { FailTest(); } }; I propose instead to do: rqGet.onsuccess = t.step_func(function(event) { assert_equals(event.target.result.property, record.property, 'event.target.result.property'); }) A last pattern (but I said two, but anyway) is: db.onerror = TestFail; which is shorter than the alternative, but it doesn't say what is failing, so I propose something like: db.onerror = t.step_func(function(e) { assert_unreached('Database error: ' + e.message) }); Much of the code will be shorter as an benefit of the first two, even if we get a few extra t.step() and t.step_func() scattered around. PassTest() and FailTest() also has another function, that is closing the database. This can be done in the "complete" callback of testharness.js: add_completion_callback(function() { if(db) db.close(); }) Issue 3 ------- The path is hardcoded to w3c-test.org, the tests would be more portable (e.g. to my laptop or to a local test framework) if it didn't use absolute URLs. So instead of: <script src="http://w3c-test.org/resources/testharness.js"></script> <script src="http://w3c-test.org/resources/testharnessreport.js"></script> Rather: <script src="/resources/testharness.js"></script> <script src="/resources/testharnessreport.js"></script> Especially testharnessreport is supposed to be overwritten by your custom report code reporting results to whatever system you want, but that won't be doable if it reads w3c's testharnessreport instead of your local version. Issue 4 ------- The Initialize() function could maybe be run from the setup() function. Issue 5 ------- No need to do var t = async_test(document.title) as var t = async_test() is equivalent. Issue 6 ------- Apache has a bug where it somehow only reads <title> tags and uses that as descriptions in automatic folder listings if it doesn't have any attributes. That feature isn't turned on in w3c-test.org, but it would be very helpful if it were, because the descriptions are good in the tests, but the filenames doesn't give as much information. Anyway, if w3c-test.org DO turn that Apache feature on, it will still not work with these tests unless you remove the id='desc' in the title. -- Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /
Received on Monday, 9 January 2012 17:12:45 UTC