Switch to direct use of OwnerSettingsServiceChromeOS::Set() in tests.

chrome/browser/chromeos/settings/stub_cros_settings_provider.h

Index: chrome/browser/chromeos/settings/stub_cros_settings_provider.h
diff --git a/chrome/browser/chromeos/settings/stub_cros_settings_provider.h b/chrome/browser/chromeos/settings/stub_cros_settings_provider.h
index 5fcb65c18f2db8f3a4762c27354b016d35952fbe..244ff2fe1cc825c3e4b4b0636a0170f7e52c7611 100644
--- a/chrome/browser/chromeos/settings/stub_cros_settings_provider.h
+++ b/chrome/browser/chromeos/settings/stub_cros_settings_provider.h
@@ -24,6 +24,9 @@ class StubCrosSettingsProvider : public CrosSettingsProvider {
   TrustedStatus PrepareTrustedValues(const base::Closure& callback) override;
   bool HandlesSetting(const std::string& path) const override;
 
+  void SetTrustedStatus(TrustedStatus status);
+  void SetCurrentUserIsOwner(bool owner);
+
  private:
   // CrosSettingsProvider implementation:
   void DoSet(const std::string& path, const base::Value& value) override;
@@ -34,6 +37,15 @@ class StubCrosSettingsProvider : public CrosSettingsProvider {
   // In-memory settings storage.
   PrefValueMap values_;
 
+  // By default, every value from Set is written. However, in some cases (e.g.

[bartfab (slow), 2015/04/10 08:38:13]

I find this comment very difficult to parse. Rewording it would help. However, I
also think that the functionality you describe here is fishy: You are abusing
Set() as a non-owner to not set but send out a notification only. If you just
want to send a notification, you should add a testing method that triggers the
notification directly.

[Ivan Podogov, 2015/04/10 09:50:53]

This behavior is actually something that some tests depend on, so I left it that
way.

[bartfab (slow), 2015/04/14 14:10:09]

This still looks very hacky. Anyone reading such a test will have no way to know
why the value passed is not actually being applied. Maybe you could at least add
a check that verifies the value being passed in matches the current value? That
way, if someone tries to modify such a test to use Set() for changing values,
they will get a CHECK() and will be pointed at this comment?

[Ivan Podogov, 2015/04/14 14:40:37]

This is actually a mimic of the current DeviceSettingsProvider::DoSet behavior
(right in the beginnning of it). The hacky thing is that KioskTest actually
depends on this behavior (and tries to set different values, so the CHECK
wouldn't help). That test should probably be rewritten from scratch anyway, but
for now that is not the task that I'm trying to accomplish...

As a compromise, I've added a warning log message (again, like in
DeviceSettingsProvider::DoSet) for such cases, so that the tests would still
work and the test author would have at least some information.

+  // enterprise-managed) it is required to retain current settings, but notify
+  // about the attempted change. That's what happens when the current user is
+  // not the owner.
+  bool current_user_is_owner_;

[bartfab (slow), 2015/04/10 08:38:14]

Nit: Initialize this.

[Ivan Podogov, 2015/04/10 09:50:53]

Done.

+
+  // Default value is TRUSTED.
+  TrustedStatus trusted_status_;

[bartfab (slow), 2015/04/10 08:38:14]

Nit: Initialize this.

[Ivan Podogov, 2015/04/10 09:50:53]

Done.

+
   DISALLOW_COPY_AND_ASSIGN(StubCrosSettingsProvider);
 };