Pass MetricsServiceClient into MetricsService, and create a simple stubbed TestMetricsServiceClient…

components/metrics.gypi

Index: components/metrics.gypi
diff --git a/components/metrics.gypi b/components/metrics.gypi
index 78e7a3cf50fb6078aef7becdf3cea612825ef105..c78c415654c9079b77552dd3d381d4ead868e8f0 100644
--- a/components/metrics.gypi
+++ b/components/metrics.gypi
@@ -55,6 +55,26 @@
       },
       'includes': [ '../build/protoc.gypi' ],
     },
+    {
+      # TODO(isherman): Remove all //chrome dependencies on this target, and

[blundell, 2014/05/20 08:08:56]

I don't understand this TODO. It's fine for //chrome code to use e.g.
TestMetricsServiceClient.

[Ilya Sherman, 2014/05/20 08:28:26]

I agree that there's no DEPS issues if //chrome code uses the
TestMetricsServiceClient.  However, in practice, I think all of the //chrome
code that does depend on the TestMetricsServiceClient will end up in the
component.  Hence, this target will eventually become obsolete.  The TODO is a
reminder to clean that up once the componentization is complete.

[blundell, 2014/05/20 09:07:07]

OK. Personally I think it would be fine to have the separate test_support
target, but I don't feel strongly about it.

On 2014/05/20 08:28:26, Ilya Sherman wrote:

+      # merge the files in this target with components_unittests.
+      'target_name': 'metrics_test_support',
+      'type': 'static_library',
+      'include_dirs': [
+        '..',
+      ],
+      'dependencies': [
+        'component_metrics_proto',
+        'metrics',
+      ],
+      'export_dependent_settings': [
+        'component_metrics_proto',
+      ],
+      'sources': [
+        'metrics/test_metrics_service_client.cc',
+        'metrics/test_metrics_service_client.h',
+      ],
+    },
   ],
   'conditions': [
     ['chromeos==1', {