DevTools: add console test helpers to new test runner & migrate a console test

third_party/WebKit/LayoutTests/http/tests/inspector/devtools-js/console/command-line-api.js

Index: third_party/WebKit/LayoutTests/http/tests/inspector/devtools-js/console/command-line-api.js
diff --git a/third_party/WebKit/LayoutTests/http/tests/inspector/devtools-js/console/command-line-api.js b/third_party/WebKit/LayoutTests/http/tests/inspector/devtools-js/console/command-line-api.js
new file mode 100644
index 0000000000000000000000000000000000000000..d1ce0590860fa8e191093fe38b281cc9140f6925
--- /dev/null
+++ b/third_party/WebKit/LayoutTests/http/tests/inspector/devtools-js/console/command-line-api.js
@@ -0,0 +1,58 @@
+// Copyright 2017 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.
+
+(async function() {
+  TestRunner.addResult('Tests that command line api works.\n');
+
+  await TestRunner.loadModule("console_test_runner");
+  await TestRunner.loadModule("elements_test_runner");
+  await TestRunner.loadPanel("console");

[caseq, 2017/07/12 01:04:33]

I wonder whether these need to be sequential. Would we have somewhat better
performance if we had something like

await Promise.all([
    TestRunner.loadModule(...),
    TestRunner.loadModule(...),
    TestRunner.loadPanel(...),
    TestRunner.loadHTML(...)
]);

?

[chenwilliam, 2017/07/12 22:02:57]

I a/b tested it (ran this test 100 times) and the perf difference is negligible.
I don't think these need to be sequential either, but I feel it's safer doing it
sequentially in case there's a race condition with loading our test runner
modules (there shouldn't be, but our existing test helpers are quite hairy).

+
+  var expressions = [
+    "String($0)",
+    "$3",
+    "String(keys([3,4]))",
+    "String(values([3,4]))",
+    "String($('#foo'))",
+    "String($('#foo', document.body))",
+    "String($('#foo', 'non-node'))",
+    "String($('#foo', $('#bar')))",
+    "String($$('p'))",
+    "String($$('p', document.body))",
+    "String($('foo'))",
+    "console.assert(keys(window).indexOf('__commandLineAPI') === -1)"
+  ];
+
+  await TestRunner.loadHTML(`
+    <p id="foo">
+      Tests that command line api works.
+    </p><p id="bar"></p>
+  `);
+
+  ElementsTestRunner.selectNodeWithId("foo", step1);
+
+  function step1(node) {
+    var expression = expressions.shift();
+    if (!expression) {
+      step2();
+      return;
+    }
+    Common.console.log("");
+    ConsoleTestRunner.evaluateInConsole(expression, step1);

[caseq, 2017/07/12 01:04:33]

Can we make it return a promise straight away? Also, if you get rid of
Common.console.log() above, this could be simpler -- we only need to wait for
the last one.

[chenwilliam, 2017/07/12 22:02:58]

Adding to @dgozman's comment, the plan is to keep the test semantics the same
and then later migrate our test API to promises.

I'm working on a script that will automatically transform our old HTML tests ->
new JS tests.

+  }
+
+  function step2() {
+    function assertNoBoundCommandLineAPI() {
+      ["__commandLineAPI", "__scopeChainForEval"].forEach(function(name) {
+        console.assert(!(name in window), "FAIL: Should be no " + name);
+      });
+    }
+    TestRunner.evaluateInPage(assertNoBoundCommandLineAPI, step3);
+  }
+
+  function step3() {
+    ConsoleTestRunner.dumpConsoleMessages();
+    TestRunner.completeTest();
+  }
+})();