File: log_replay_socket.h

package info (click to toggle)
chromium 139.0.7258.127-1
  • links: PTS, VCS
  • area: main
  • in suites:
  • size: 6,122,068 kB
  • sloc: cpp: 35,100,771; ansic: 7,163,530; javascript: 4,103,002; python: 1,436,920; asm: 946,517; xml: 746,709; pascal: 187,653; perl: 88,691; sh: 88,436; objc: 79,953; sql: 51,488; cs: 44,583; fortran: 24,137; makefile: 22,147; tcl: 15,277; php: 13,980; yacc: 8,984; ruby: 7,485; awk: 3,720; lisp: 3,096; lex: 1,327; ada: 727; jsp: 228; sed: 36
file content (66 lines) | stat: -rw-r--r-- 2,979 bytes parent folder | download | duplicates (11)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
// Copyright 2018 The Chromium Authors
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#ifndef CHROME_TEST_CHROMEDRIVER_LOG_REPLAY_LOG_REPLAY_SOCKET_H_
#define CHROME_TEST_CHROMEDRIVER_LOG_REPLAY_LOG_REPLAY_SOCKET_H_

#include <string>

#include "chrome/test/chromedriver/log_replay/devtools_log_reader.h"
#include "chrome/test/chromedriver/net/sync_websocket.h"

// A "WebSocket" class for getting commands from a log file.
//
// Instead of communicating with DevTools, this implementation looks up the
// intended results of commands in a ChromeDriver log file. This enables the
// DevTools-side commands and responses to be replayed from a past session.
class LogReplaySocket : public SyncWebSocket {
 public:
  // Initialize a LogReplaySocket with a ChromeDriver log.
  explicit LogReplaySocket(const base::FilePath& log_path);
  ~LogReplaySocket() override;

  // Set the ID of this instance. This is intended to be the id_ of the
  // DevToolsClientImpl instance that owns this LogReplaySocket, which is
  // an identifier for the renderer process that this DevTools instance
  // was talking to. Since ChromeDriver logs often include messages from
  // multiple renderers, this enables a LogReplaySocket to know which
  // of these messages it should observe. Note that the id_ corresponds
  // to a frameID or window ID, so it stays stable between the old and
  // replay sessions (this is in contrast to sessionIDs, which change).
  void SetId(const std::string& socket_id) override;

  // The Connection methods here basically just mock out behavior of a
  // real SyncWebSocket
  bool IsConnected() override;
  bool Connect(const GURL& url) override;

  // "Sends" a message to the "renderer". This doesn't really give us any
  // actions to do (since we would know how to respond even if the message
  // wasn't sent). However, we need to keep track of the sequential id of
  // the latest message because we don't want to return the responses for
  // messages that have not been sent yet.
  bool Send(const std::string& message) override;

  // Return the next message (event or response) in the |message| parameter.
  // timeout is ignored (since the response is either ready or there is
  // some kind of problem with the log).
  StatusCode ReceiveNextMessage(std::string* message,
                                const Timeout& timeout) override;

  // Returns true if we "should" have the next message - that is, the next
  // message in the log either is an event or a response for a message that
  // has been sent.
  bool HasNextMessage() override;

 private:
  // Return the next WebSocket entry in the log. Returns requests only if
  // |include_requests| is true
  std::unique_ptr<LogEntry> GetNextSocketEntry(bool include_requests);
  bool connected_;
  int max_id_;
  DevToolsLogReader log_reader_;
  std::string socket_id_;
};

#endif  // CHROME_TEST_CHROMEDRIVER_LOG_REPLAY_LOG_REPLAY_SOCKET_H_