RulesRegistry for declarative APIs.

chrome/test/data/extensions/api_test/declarative/api/background.js

Index: chrome/test/data/extensions/api_test/declarative/api/background.js
diff --git a/chrome/test/data/extensions/api_test/declarative/api/background.js b/chrome/test/data/extensions/api_test/declarative/api/background.js
new file mode 100644
index 0000000000000000000000000000000000000000..0d8077b680c7c6b8ea8f04727cefa0d645c94c76
--- /dev/null
+++ b/chrome/test/data/extensions/api_test/declarative/api/background.js
@@ -0,0 +1,154 @@
+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+var declarative = chrome.experimental.declarative;
+
+function createTestCondition(opt_testParameter) {
+  var result = {
+    "instanceType": "experimental.declarative.TestCondition"
+  };
+  if (opt_testParameter) {
+    result["testParameter"] = opt_testParameter;
+  }
+  return result;
+}
+
+function createTestAction(opt_testParameter) {
+  var result = {
+    "instanceType": "experimental.declarative.TestAction"
+  };
+  if (opt_testParameter) {
+    result["testParameter"] = opt_testParameter;
+  }
+  return result;
+}
+
+var inputRule0 = {
+  // No 'id', this should be filled by the API
+  "conditions": [createTestCondition("test1"), createTestCondition("test2")],
+  "actions": [createTestAction("action1"), createTestAction("action2")]
+  // No 'priority', this should be filled by the API
+}
+
+var outputRule0 = {
+  "id": "_0_",
+  "conditions": [createTestCondition("test1"), createTestCondition("test2")],
+  "actions": [createTestAction("action1"), createTestAction("action2")],
+  "priority": 100
+}
+
+var inputRule1 = {
+  "id": "my_rule_id",
+  "conditions": [],
+  "actions": [],
+  "priority": 10
+}
+
+var outputRule1 = inputRule1;
+
+var inputRule2 = {
+  // No 'id', this should be filled by the API
+  "conditions": [createTestCondition("test3")],
+  "actions": [createTestAction("action3")]
+  // No 'priority', this should be filled by the API
+}
+
+var outputRule2 = {
+  "id": "_1_",
+  "conditions": [createTestCondition("test3")],
+  "actions": [createTestAction("action1")],
+  "priority": 100
+}
+
+chrome.test.runTests([
+  // Add adding two simple rules and check that their optional fields are set
+  // correctly in the call back function.
+  function testAddRules() {
+    var callback = function(rules) {
+      chrome.test.assertEq(2, rules.length);
+      // API should have generated id and priority fields.
+      chrome.test.assertTrue("id" in rules[0]);
+      chrome.test.assertEq(100, rules[0].priority);
+      chrome.test.assertEq(outputRule0, rules[0]);
+      chrome.test.assertEq(outputRule1, rules[1]);

[not at google - send to devlin, 2012/02/02 11:59:16]

perhaps more concise as

chrome.test.assertEq([outputRule0, outputRule1], rules);

(since you also wouldn't need the rules.length == 2 check)

also, I've seen other tests define assertTrue/assertEq at the top rather than
typing "chrome.test" everywhere.

[battre, 2012/02/02 19:12:36]

I have changed this to 
chrome.test.assertEq([outputRule0, outputRule1], rules);

I have not removed the rules.length == 2 here because I need to check that
rules.length>0 for the "id" in rules[0] test. I'd like to keep that on top
because it generates more sensible error messages that way in case something
breaks.

I have removed the rules.length test in other locations, though.

[not at google - send to devlin, 2012/02/03 13:06:20]

Isn't the priority=100 check redundant though, since outputRule0 has
priority=100?

[battre, 2012/02/06 16:21:04]

I had the separate test to create simpler to read failure reports, but I am fine
with removing this as well.

Done.

+      chrome.test.succeed();
+    };
+    declarative.testEvent.addRules([inputRule0, inputRule1], callback);
+  },
+  // Check that getRules() returns all rules if no filter is passed.
+  function testGetRules() {
+    var callback = function(rules) {
+      chrome.test.assertEq(2, rules.length);
+      // We are not given any gurantee on the order in which rules are returned.
+      chrome.test.assertTrue(
+        (chrome.test.checkDeepEq(outputRule0, rules[0]) &&
+         chrome.test.checkDeepEq(outputRule1, rules[1])) ||
+        (chrome.test.checkDeepEq(outputRule0, rules[1]) &&
+         chrome.test.checkDeepEq(outputRule1, rules[0])))
+      chrome.test.succeed();
+    }
+    declarative.testEvent.getRules([], callback);

[not at google - send to devlin, 2012/02/02 11:59:16]

Why is [] get all rules, I would have though this would return no rules?

Other APIs have the convention of null/undefined implying "everything"; I
suggest you follow that.

[battre, 2012/02/02 19:12:36]

This does not work with SchemaGeneratedBindings as of now.

If I change the schema so that the both parameter of getRules are optional and
pass "null, callback" or "undefined, callback", the binding layer creates an
empty list in both cases. If we want to change this behavior, I suggest that we
do in a separate CL. It might break a lot.

[not at google - send to devlin, 2012/02/03 13:06:20]

That's surprising?  The Storage API uses the tactic of passing through
null/undefined in Get to get everything.

See manifest:
http://code.google.com/codesearch#OAMlx_jo-ck/src/chrome/common/extensions/ap...
Code:
http://code.google.com/codesearch#OAMlx_jo-ck/src/chrome/browser/extensions/s...

Can you find where the bindings layer turns null -> [] ?  That would seem like a
bug to me...

[battre, 2012/02/06 16:21:04]

I have no idea why it did not work last time.

Done.

+  },
+  // Check that getRules() returns all rules if rules are filtered by ID.
+  function testSelectiveGetRules() {
+    var callback = function(rules) {
+      chrome.test.assertEq(1, rules.length);
+      chrome.test.assertEq(outputRule1, rules[0]);
+      chrome.test.succeed();
+    }
+    declarative.testEvent.getRules(["my_rule_id"], callback);
+  },
+  // Check that we can remove individual rules.
+  function testSelectiveRemoveRules() {
+    var callback = function(rules) {
+      chrome.test.succeed();
+    }
+    declarative.testEvent.removeRules(["my_rule_id"], callback);
+  },
+  // Check that after removal, the rules are really gone.
+  function testGetRemainingRules() {
+    var callback = function(rules) {
+      chrome.test.assertEq(1, rules.length);
+      chrome.test.assertEq(outputRule0, rules[0]);
+      chrome.test.succeed();
+    }
+    declarative.testEvent.getRules([], callback);
+  },
+  // Check that rules are assigned unique IDs.
+  function testIdGeneration() {
+    var callback = function(rules) {
+      chrome.test.assertEq(1, rules.length);
+      // API should have generated id and priority fields.
+      chrome.test.assertTrue("id" in rules[0]);
+      // The IDs should be distinct.
+      chrome.test.assertFalse(outputRule0["id"] === rules[0]["id"]);
+      chrome.test.succeed();
+    };
+    declarative.testEvent.addRules([inputRule2], callback);
+  },
+  // Check that we can remove all rules at once.
+  function testRemovingAllRules() {
+    var callback = function() {
+      chrome.test.succeed();
+    }
+    declarative.testEvent.removeRules([], callback);

[not at google - send to devlin, 2012/02/02 11:59:16]

See comment above about getRules.

[battre, 2012/02/02 19:12:36]

see above

[battre, 2012/02/06 16:21:04]

Done.

+  },
+  // Check that the rules are actually gone.
+  function testAllRulesRemoved() {
+    var callback = function(rules) {
+      chrome.test.assertEq(0, rules.length);
+      chrome.test.succeed();
+    }
+    declarative.testEvent.getRules([], callback);
+  },
+  // Finally we add one additional rule, to check that is is removed
+  // on page unload.
+  function testAddRules() {
+    var callback = function(rules) {
+      chrome.test.assertEq(1, rules.length);
+      chrome.test.succeed();
+    };
+    declarative.testEvent.addRules([inputRule0], callback);

[not at google - send to devlin, 2012/02/02 11:59:16]

Another important test is that the condition/action validation works.  As in, it
rejects calls using the wrong actions etc.

In fact, the only real reason we need these API tests is so that the renderer
logic is tested; and the renderer logic basically consists of that validation
(plus the chrome.Event thin wrapping around the API itself).

Everything else can hopefully be done with unit tests, or in the worst case, be
done with an "API bindings test" (or whatever aa has been calling it), which
just tests the browser-side bindings (see See
http://code.google.com/codesearch#OAMlx_jo-ck/src/chrome/browser/extensions/e...).

[battre, 2012/02/02 19:12:36]

Done.

+  },
+  ]);