DomStorageBrowserTest sanity check

DomStorageBrowserTest sanity check
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=130762

[michaeln, 2012-04-03 21:09:47]

i have to move the file out of the 'in_process_webkit' directory, but
otherwise... ptal

[michaeln, 2012-04-03 21:12:37]

https://chromiumcodereview.appspot.com/9956117/diff/1005/content/test/data/do...
File content/test/data/dom_storage/sanity_check.js (right):

https://chromiumcodereview.appspot.com/9956117/diff/1005/content/test/data/do...
content/test/data/dom_storage/sanity_check.js:38: storage["name"] = "value";
i should also add some calls to the storage.key(indx) method

[michaeln, 2012-04-03 21:40:36]

https://chromiumcodereview.appspot.com/9956117/diff/1005/content/browser/in_p...
File content/browser/in_process_webkit/dom_storage_browsertest.cc (right):

https://chromiumcodereview.appspot.com/9956117/diff/1005/content/browser/in_p...
content/browser/in_process_webkit/dom_storage_browsertest.cc:36:
ui_test_utils::NavigateToURLBlockUntilNavigationsComplete(
oh well... this doesn't unblock upon the 2nd navigation to #pass ref so the test
times out...

[michaeln, 2012-04-03 21:43:29]

fixed the timeout problem in snapshot 3, make the page behave asyncly (i
anticipate adding other tests in the future that won't be doable syncly and want
the basic test harness to work for them too)

[michaeln, 2012-04-03 21:52:17]

added calls to the .key() method in snapshot 4

[michaeln, 2012-04-04 01:46:34]

moved the file in snapshot 5

[michaeln, 2012-04-04 18:11:35]

ping

[jsbell, 2012-04-04 18:37:56]

overall lgtm

http://codereview.chromium.org/9956117/diff/7002/content/browser/dom_storage/...
File content/browser/dom_storage/dom_storage_browsertest.cc (left):

http://codereview.chromium.org/9956117/diff/7002/content/browser/dom_storage/...
content/browser/dom_storage/dom_storage_browsertest.cc:109:
AppendASCII("events")) {
Will you bring back any of the existing layout tests as browser tests, or just
keeping the sanity check + unit tests?

http://codereview.chromium.org/9956117/diff/7002/content/test/data/dom_storag...
File content/test/data/dom_storage/sanity_check.js (right):

http://codereview.chromium.org/9956117/diff/7002/content/test/data/dom_storag...
content/test/data/dom_storage/sanity_check.js:70: if (lhs != rhs)
Nit: I'd prefer the stricter !== comparison, which per the DOM Storage spec
would require comparing with null vs. undefined

http://codereview.chromium.org/9956117/diff/7002/content/test/data/dom_storag...
content/test/data/dom_storage/sanity_check.js:76: while (x.length < minimumSize)
Per dgrogan's advice to me, watch out for this style being slow on the win/mac
bots. You may want to use the Array(n).join(x) trick; I guess n would be
Math.ceil(minimumSize / x.length)

Also (based on my recent max-value-size-for-IDB-tests), if the limit is based on
byte count not character count, be paranoid about whether the strings end up
being UTF-16 or UTF-8, and it might vary per platform (leading to testing two
different sizes on win bots vs. mac/linux bots). (I ended up using a string of
"\u0100" since that encodes to the same length in both.)

[michaeln, 2012-04-04 19:03:21]

http://codereview.chromium.org/9956117/diff/7002/content/browser/dom_storage/...
File content/browser/dom_storage/dom_storage_browsertest.cc (left):

http://codereview.chromium.org/9956117/diff/7002/content/browser/dom_storage/...
content/browser/dom_storage/dom_storage_browsertest.cc:109:
AppendASCII("events")) {
On 2012/04/04 18:37:56, jsbell wrote:
> Will you bring back any of the existing layout tests as browser tests, or just
> keeping the sanity check + unit tests?

Mostly TBD. We do run the layout tests in DRT, not sure its worth running them
here too. 

At this time, I'm mostly looking to put in a robust integration test thats easy
to maintain. Layout tests fail that criteria by being in a separate repository
and having potentially multiple separate expected result files.

http://codereview.chromium.org/9956117/diff/7002/content/test/data/dom_storag...
File content/test/data/dom_storage/sanity_check.js (right):

http://codereview.chromium.org/9956117/diff/7002/content/test/data/dom_storag...
content/test/data/dom_storage/sanity_check.js:70: if (lhs != rhs)
On 2012/04/04 18:37:56, jsbell wrote:
> Nit: I'd prefer the stricter !== comparison, which per the DOM Storage spec
> would require comparing with null vs. undefined

Right, some of my checkEquals should be testing against null.

http://codereview.chromium.org/9956117/diff/7002/content/test/data/dom_storag...
content/test/data/dom_storage/sanity_check.js:76: while (x.length < minimumSize)
On 2012/04/04 18:37:56, jsbell wrote:
> Per dgrogan's advice to me, watch out for this style being slow on the win/mac
> bots. You may want to use the Array(n).join(x) trick; I guess n would be
> Math.ceil(minimumSize / x.length)

At the sizes i'm working with, i haven't noticed this being at all slow, but you
say Array().join(x) is actually faster... ok... i'll switch to doing that here.

> Also (based on my recent max-value-size-for-IDB-tests), if the limit is based
on
> byte count not character count, be paranoid about whether the strings end up
> being UTF-16 or UTF-8, and it might vary per platform (leading to testing two
> different sizes on win bots vs. mac/linux bots). (I ended up using a string of
> "\u0100" since that encodes to the same length in both.)

It's all UTF-16 and values are treated like binary data in the backend.

[jam, 2012-04-04 21:56:00]

chrome/chrome_tests.gypi lgtm