Change the battery-status layout tests to use JS mocks.

third_party/WebKit/LayoutTests/resources/mojo-helpers.js

Index: third_party/WebKit/LayoutTests/resources/mojo-helpers.js
diff --git a/third_party/WebKit/LayoutTests/resources/mojo-helpers.js b/third_party/WebKit/LayoutTests/resources/mojo-helpers.js
index db7a6264bf3d0f6219356e6ff2a3b89c06e6518f..7cc4668cdf4e812e74a9ace77ba1feb4e3a2d5e6 100644
--- a/third_party/WebKit/LayoutTests/resources/mojo-helpers.js
+++ b/third_party/WebKit/LayoutTests/resources/mojo-helpers.js
@@ -34,10 +34,13 @@ define('Mojo Helpers', [
     'content/public/renderer/frame_service_registry',
     'content/public/renderer/service_registry',
 ], (core, router, support, frameServiceRegistry, serviceRegistry) => {
-  add_completion_callback(() => {
-    frameServiceRegistry.clearServiceOverridesForTesting();
-    serviceRegistry.clearServiceOverridesForTesting();
-  });
+  let tearDown = () => {
+      frameServiceRegistry.clearServiceOverridesForTesting();

[dcheng, 2016/03/31 01:31:40]

If a test forgot to call this, does this mean the JS mocks would leak between
tests?

[Sam McNally, 2016/03/31 01:58:24]

Yes, if they reuse the same frame and/or process. If every test goes through
mojo_test or loadMojoModules to get at the mojo bindings, we should avoid that
problem. The leak detector notices when that happens too.

A related issue can occur if a per-process API implementation holds onto its
mojo message pipe; if another test targets the same API and runs in the same
process, it can cause problems if the API implementation doesn't reconnect. The
usb layout tests currently have this issue.

+      serviceRegistry.clearServiceOverridesForTesting();
+    }
+  addEventListener('unload', tearDown);
+  if (window.add_completion_callback)
+    add_completion_callback(tearDown);
 
   return {
     core,