Add cache test.

Add a read cache test.
We could just add a parameter to a similar test, but I think most of them have enough parameters already, and this keeps it simpler.

BUG=137764
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=151735

[jsbell, 2012-08-09 17:58:18]

lgtm with nit and commentary

https://chromiumcodereview.appspot.com/10854046/diff/4/chrome/test/data/index...
File chrome/test/data/indexeddb/perf_shared.js (right):

https://chromiumcodereview.appspot.com/10854046/diff/4/chrome/test/data/index...
chrome/test/data/indexeddb/perf_shared.js:322: request.onerror = onError;
This doesn't verify that a value was returned (success event with result
non-null vs. null), which is *mostly* fine for the test itself, but means we may
not catch logic errors in the test where we're requesting keys that don't exist.

Although it shouldn't make a difference now, I could imagine a future caching
scheme where the min/max keys of the source were known and out-of-range requests
were optimized, and/or the caching behavior of hits vs. misses was different
(e.g. if hits were cached but misses were not). Without verifying that a value
was read we might be testing the wrong thing.

(That may inspire a few more perf test cases as well.)

https://chromiumcodereview.appspot.com/10854046/diff/4/chrome/test/data/index...
File chrome/test/data/indexeddb/perf_test.js (right):

https://chromiumcodereview.appspot.com/10854046/diff/4/chrome/test/data/index...
chrome/test/data/indexeddb/perf_test.js:287: function () { return "test value";
});
Nit: space between function keyword and ()

https://chromiumcodereview.appspot.com/10854046/diff/4/chrome/test/data/index...
chrome/test/data/indexeddb/perf_test.js:298: function runOneBatch(db) {
This runOneBatch() pattern seems to be re-used in many tests. Factor out?

[ericu, 2012-08-15 17:56:22]

https://chromiumcodereview.appspot.com/10854046/diff/4/chrome/test/data/index...
File chrome/test/data/indexeddb/perf_shared.js (right):

https://chromiumcodereview.appspot.com/10854046/diff/4/chrome/test/data/index...
chrome/test/data/indexeddb/perf_shared.js:322: request.onerror = onError;
On 2012/08/09 17:58:18, jsbell wrote:
> This doesn't verify that a value was returned (success event with result
> non-null vs. null), which is *mostly* fine for the test itself, but means we
may
> not catch logic errors in the test where we're requesting keys that don't
exist.
> 
> Although it shouldn't make a difference now, I could imagine a future caching
> scheme where the min/max keys of the source were known and out-of-range
requests
> were optimized, and/or the caching behavior of hits vs. misses was different
> (e.g. if hits were cached but misses were not). Without verifying that a value
> was read we might be testing the wrong thing.
> 
> (That may inspire a few more perf test cases as well.)

Added it in a couple of places.

https://chromiumcodereview.appspot.com/10854046/diff/4/chrome/test/data/index...
File chrome/test/data/indexeddb/perf_test.js (right):

https://chromiumcodereview.appspot.com/10854046/diff/4/chrome/test/data/index...
chrome/test/data/indexeddb/perf_test.js:287: function () { return "test value";
});
On 2012/08/09 17:58:18, jsbell wrote:
> Nit: space between function keyword and ()

Done.

https://chromiumcodereview.appspot.com/10854046/diff/4/chrome/test/data/index...
chrome/test/data/indexeddb/perf_test.js:298: function runOneBatch(db) {
On 2012/08/09 17:58:18, jsbell wrote:
> This runOneBatch() pattern seems to be re-used in many tests. Factor out?

It's used in 3 places, but one is actually different than the others [running
the transactions from a timer instead of just chaining them together].  I pulled
out the common pattern from the 2 that matched, and that'll probably get reused
in a bunch more tests.

[commit-bot: I haz the power, 2012-08-15 17:57:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ericu@chromium.org/10854046/9001

[commit-bot: I haz the power, 2012-08-15 20:29:49]

Change committed as 151735