Tests for the Copresence API.

components/copresence/public/copresence_client.h

 // Copyright 2014 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 COMPONENTS_COPRESENCE_PUBLIC_COPRESENCE_CLIENT_H_
 #define COMPONENTS_COPRESENCE_PUBLIC_COPRESENCE_CLIENT_H_
 
 #include <string>
 #include <vector>
 
@@ skipping 23 matching lines @@
   std::string app_id;
   StatusCallback callback;
 };
 
 // The CopresenceClient class is the central interface for Copresence
 // functionality. This class handles all the initialization and delegation of
 // copresence tasks. Any user of copresence only needs to interact with this
 // client.
 class CopresenceClient : public base::SupportsWeakPtr<CopresenceClient> {
  public:
+  CopresenceClient();
+  virtual ~CopresenceClient();
+
   // The delegate must outlive us.
-  explicit CopresenceClient(CopresenceClientDelegate* delegate);
-  virtual ~CopresenceClient();
+  virtual void Initialize(CopresenceClientDelegate* delegate);

[not at google - send to devlin, 2014/08/06 21:45:27]

I don't really like having separate Initialize functions, it adds complexity to
object construction. If an object isn't valid after construction then you should
have a static Create method which constructs + initializes, then make the
constructor+Initialize private. then make sure that the correct Create
implementation is linked in.

[Charlie, 2014/08/06 21:54:41]

I'm not quite following what you're suggesting. But would you be ok with a
protected constructor that the MockCopresenceClient uses to inject all
dependencies? Then we could revert to the old public constructor.

On 2014/08/06 21:45:27, kalman wrote:

[not at google - send to devlin, 2014/08/06 22:02:00]

I don't think my suggestion is actually implementable because chances are the
mock and the real copresence clients can be linked together in the same binary,
somehow.

but I really hope it's possible to implement this mock stuff without exposing an
Initialize method or a protected constructor. like, it makes sense for the
Delegate to always be passed in on construction. odd that one code path (to
construct the real one) ends up calling Initialize, and the other one (for
testing) doesn't.

[Charlie, 2014/08/07 22:24:15]

Switching to a Create() method per the CL-level thread. In order for subclassing
to work at all, it seems like we need at least a protected constructor.

 
   // This method will execute a report request. Each report request can have
   // multiple (un)publishes, (un)subscribes. This will ensure that once the
   // client is initialized, it sends all request to the server and handles
   // the response. If an error is encountered, the status callback is used
   // to relay it to the requester.
-  void ExecuteReportRequest(copresence::ReportRequest request,
-                            const std::string& app_id,
-                            const StatusCallback& callback);
+  virtual void ExecuteReportRequest(copresence::ReportRequest request,
+                                    const std::string& app_id,
+                                    const StatusCallback& callback);
 
   // Called before the API (and thus the Client) is destructed.
   void Shutdown();
 
  private:
   void CompleteInitialization();
   void InitStepComplete(const std::string& step, bool success);
 
   CopresenceClientDelegate* delegate_;
   bool init_failed_;
   std::vector<PendingRequest> pending_requests_queue_;
 
   // TODO(rkc): This code is almost identical to what we use in feedback to
   // perform multiple blocking tasks and then run a post process method. Look
   // into refactoring it all out to a common construct, like maybe a
   // PostMultipleTasksAndReply?
   size_t pending_init_operations_;
 
   scoped_ptr<RpcHandler> rpc_handler_;
 
   DISALLOW_COPY_AND_ASSIGN(CopresenceClient);
 };
 
 }  // namespace copresence
 
 #endif  // COMPONENTS_COPRESENCE_PUBLIC_COPRESENCE_CLIENT_H_