Refactor PluginService to take PluginList as a dependency.

content/test/mock_plugin_service.h

+// Copyright (c) 2011 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_TEST_MOCK_PLUGIN_SERVICE_H_
+#define CONTENT_TEST_MOCK_PLUGIN_SERVICE_H_
+#pragma once
+
+#include "content/browser/plugin_service.h"
+
+namespace webkit {
+namespace npapi {
+class PluginList;
+}
+}
+
+// This class can be used in tests to bypass the actual plugin loading logic. It
+// is meant to be used in conjection with MockPluginList and will perform a
+// synchronous load of plugins on the thread on which the GetPlugin* methods
+// were called. Note that the callbacks will still be run off the message loop.
+//
+// If you're wondering how this works in conjunction with the PluginService
+// singleton, the answer is to refactor your component to use dependency
+// injection to take an instance of PluginService, store it as a member, and
+// pass in an instance of this during tests.
+class MockPluginService : public PluginService {

[Bernhard Bauer, 2011/11/07 22:37:50]

Could we call this TestingPluginService? If I read "mock", I assume it's
something I can set expectations on.

[Robert Sesek, 2011/11/07 23:05:49]

Sure. The other "mocks" are also not true GMock mocks, so I went with that.

+ public:
+  MockPluginService(webkit::npapi::PluginList* plugin_list);

[Bernhard Bauer, 2011/11/07 22:37:50]

Could you demand a MockPluginList here, or are there cases where we'd want to
pass in a real PluginList?

[Robert Sesek, 2011/11/07 23:05:49]

I thought about it, but there's no reason to be that specific yet.

+  virtual ~MockPluginService();
+
+  // PluginService:
+  virtual void GetPlugins(const GetPluginsCallback& cb) OVERRIDE;
+  virtual void GetPluginGroups(const GetPluginGroupsCallback& cb) OVERRIDE;
+};
+
+#endif  // CONTENT_TEST_MOCK_PLUGIN_SERVICE_H_