Add DeviceSettingProvider unit tests.

chrome/browser/metrics/metrics_service.h

Index: chrome/browser/metrics/metrics_service.h
diff --git a/chrome/browser/metrics/metrics_service.h b/chrome/browser/metrics/metrics_service.h
index 91eb0ead3f5b28fbc8cf06e1fdb26ecaf76686a0..d97a1bca785b850eecc864973056061e9db46b9e 100644
--- a/chrome/browser/metrics/metrics_service.h
+++ b/chrome/browser/metrics/metrics_service.h
@@ -43,6 +43,10 @@ class DictionaryValue;
 class MessageLoopProxy;
 }
 
+namespace chromeos {
+class DeviceSettingsProviderTest;
+}
+
 namespace content {
 class RenderProcessHost;
 }
@@ -133,6 +137,12 @@ class MetricsService : public content::NotificationObserver,
   // Set the dirty flag, which will require a later call to LogCleanShutdown().
   static void LogNeedForCleanShutdown();
 
+ protected:
+  // Constructor used in tests.
+  explicit MetricsService(bool active);
+
+  friend class chromeos::DeviceSettingsProviderTest;

[jar (doing other things), 2012/03/16 16:29:16]

I'm always leery about adding friendship to classes. It makes the class harder
to read, as there is always a fear that distant code will manipulate innards in
unknown ways.  When possible, it is always nicer to have a limited interface
that server the needs of this would-be new-friend. 

It is helpful that the class has the word "Test" in it, which generally assures
me that the tinkering won't happen in production, but it also means that if a
person modifies the MetricsService class, they must be aware of any/all accesses
made by a second class through undocumented interfaces :-(.

If you can clarify the limited set of interfaces and mutations you'd need for
the other class, that would be IMO much cleaner (more readable, maintainable,
etc.)

[pastarmovj, 2012/03/21 15:23:27]

I decided to split this CL and get all MetricsService related changes in another
one so this is reverted. 
I was anyhow planning to do some refactoring there like adding a virtual base
class to server as a base for mocking the MetricsService in tests. Also the
utility functions that are now used to turn on and off the metrics reporting
seem to be a little chaotic and I remember there were users directly accessing
the MetricsService while other user the OptionsUtil class. So I will consolidate
those as well if possible in this other CL. Might take a while till I get to
this task though.

+
  private:
   // The MetricsService has a lifecycle that is stored as a state.
   // See metrics_service.cc for description of this lifecycle.