Introduce ContentSettingsClient interface

components/content_settings.gypi

Index: components/content_settings.gypi
diff --git a/components/content_settings.gypi b/components/content_settings.gypi
index 79694697ca98652475faf0b590e6376498aadff5..913bf1ad391cfe6624d27a2e43955b94e670a260 100644
--- a/components/content_settings.gypi
+++ b/components/content_settings.gypi
@@ -18,6 +18,8 @@
       ],
       'sources': [
         # Note: sources list duplicated in GN build.
+        'content_settings/core/browser/content_settings_client.cc',
+        'content_settings/core/browser/content_settings_client.h',
         'content_settings/core/browser/content_settings_details.cc',
         'content_settings/core/browser/content_settings_details.h',
         'content_settings/core/browser/content_settings_observer.h',
@@ -57,5 +59,24 @@
         'content_settings/core/common/permission_request_id.cc',
       ],
     },
+    {
+      # GN version: //components/content_settings/core/browser
+      'target_name': 'content_settings_core_browser_test_utils',
+      'type': 'static_library',
+      'dependencies': [
+        '../base/base.gyp:base',
+        'content_settings_core_browser',
+      ],
+      'include_dirs': [
+        '..',
+      ],
+      'sources': [
+        # Note: sources list duplicated in GN build.
+        'content_settings/core/browser/stub_content_settings_client.cc',

[blundell, 2014/10/09 05:50:50]

I think this could live in content_settings/core/test and be called
content_settings_core_test_utils.

[blundell, 2014/10/09 05:50:50]

nit: these objects would conventionally be called test_foo (e.g.,
test_content_settings_client)

[vabr (Chromium), 2014/10/09 13:47:54]

Done.

[vabr (Chromium), 2014/10/09 13:47:54]

I tried to copy the structure we ended up with in password manager:
PasswordManagerClient is the interface
StubPasswordManagerClient stubs the pure virtual methods for convenience
TestPasswordManagerClient/MockPasswordManagerClient are typically local to a
test, inherit from Stub* and modify methods relevant to the test.

Therefore I would like to stick with Stub* here as well. What do you think?

[blundell, 2014/10/09 14:00:40]

Heh, now that you mention it, I've always had a problem with the way that
Autofill/PasswordManager work in this context. What is the motivation to keep an
empty StubContentSettingsClient? Why not fold all the logic that tests use into
that class, making it configurable as necessary so that different tests can do
the different kinds of mocking they want to do? I don't see any benefit to
having to have slightly different test versions of FooClient across N different
tests vs. one TestFooClient that is configurable to work in all the N tests plus
be used out-of-the-box for new tests that get developed.

+        'content_settings/core/browser/stub_content_settings_client.h',
+        'content_settings/core/browser/stub_local_shared_objects_counter.cc',
+        'content_settings/core/browser/stub_local_shared_objects_counter.h',
+      ],
+    },
   ],
 }