W3C home > Mailing lists > Public > public-webapps-testsuite@w3.org > March 2012

RE: Updates to Microsoft IndexedDB test cases

From: Kris Krueger <krisk@microsoft.com>
Date: Tue, 6 Mar 2012 23:39:29 +0000
To: Odin Hørthe Omdal <odinho@opera.com>, "public-webapps-testsuite@w3.org" <public-webapps-testsuite@w3.org>, Alex Kuang <Alex.Kuang@microsoft.com>, "James Graham (jgraham@opera.com)" <jgraham@opera.com>
Message-ID: <0A605FCDA3A4DC45A98B0DDD1C5351A7035BE736@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
James can you update testharness.js with the new exceptions?  Alex could do it as well if that helps.

-Thx

> you're testing exceptions manually instead of using  assert_throws(). That is possibly because testharness.js needs to be updated to take the new values


-----Original Message-----
From: Odin Hørthe Omdal [mailto:odinho@opera.com] 
Sent: Friday, March 02, 2012 4:33 PM
To: public-webapps-testsuite@w3.org; Alex Kuang
Subject: Re: Updates to Microsoft IndexedDB test cases

> From: "Alex Kuang" <Alex.Kuang@microsoft.com> We have made some 
> updates to our submitted IndexedDB test cases:
>  1) Adding additional test cases for IndexedDB APIs.
>  2) Updating previously submitted IndexedDB test cases that use the current database open API and upgradeneeded event.

>  3) Removing createObjectStore and transaction tests because they are no longer compliant to the latest W3C spec.


I looked through them earlier today, and from the quick glance you seem to have addressed the comments I had in my earlier review.


Ah, I actually did find one issue going through some random files, you're testing exceptions manually instead of using  assert_throws(). That is possibly because testharness.js needs to be updated to take the new values. I've put up a review of what I've been using locally myself on github[1]. It will probably change in some way though, based on reviews, but it's good enough in the meantime.




The IndexedDB API isn't easily testable without quite a lot of setup before each test. You've taken a bit different route than what I did, but I'm still unsure about what makes the most sense. It's possible to either have the boilerplate in each file, or have a bit bigger framework making the tests rely on some magic functions (like createdb) at the start. I opted for the latter because when reading several tests, the real test might be a bit easier to spot. Plus it makes it harder to forget to define fail handlers on events that are not meant to be fired.


I'll find out how my port of your earlier tests diverge from this new version - and where they differ, merge the result.


This new testsuite, would not need a port as I did to the old, but since I've already done it I'll at least stick to it a while. :-)




1. https://github.com/Velmont/testharness.js/commit/f28fc88245aee56f0cbbe3ec9bca22336da9a3d9#commitcomment-1037648

--
Odin, Opera





Received on Tuesday, 6 March 2012 23:40:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 April 2014 14:15:59 UTC