File: log_replay_socket.h

package info (click to toggle)
chromium 138.0.7204.183-1
  • links: PTS, VCS
  • area: main
  • in suites: trixie
  • size: 6,071,908 kB
  • sloc: cpp: 34,937,088; ansic: 7,176,967; javascript: 4,110,704; python: 1,419,953; asm: 946,768; xml: 739,971; pascal: 187,324; sh: 89,623; perl: 88,663; objc: 79,944; sql: 50,304; cs: 41,786; fortran: 24,137; makefile: 21,806; php: 13,980; tcl: 13,166; yacc: 8,925; 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 (10)
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_