The real participant mode is specific to Talkbuchet CLI and intended
only for development. This mode does not use Talkbuchet.js at all, and
just uses the real Talk app in the Nextcloud server to join the room
and, optionally, the call with a real participant.
Although it would provide the most accurate results in most cases it is
not suitable for load tests of the server or other clients, as the use
of real participants limits the number of participants that can be
created by the system running the CLI without saturating the CPU (unless
a remote Selenium server with plenty of available sessions is used).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The variables need to be exposed through a function, as the CLI has to
copy the elements defined by Talkbuchet.js to the global scope when
loading it, but if a variable is later overwritten the copied one would
not reflect it.
Note that CLI does not directly use the exposed publishers, subscribers
and virtual participants; they are just exposed in case they need to be
used by custom scripts.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Siege and virtual participant modes are independent one from the other,
so at any given time the CLI only provides the global functions that
belong to the mode currently active. By default the CLI starts in siege
mode.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In order to add support for the virtual participant mode in a following
commit the Talkbuchet wrapper class was split in a base class with the
common code and a subclass with the code specific to siege mode.
Similarly, the global helper functions were also split between the
common ones and the siege specific ones, which will only be defined when
"switchToSiegeMode()" is called (done by default).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When Talkbuchet CLI is executed through the Talkbuchet runner the
browser available in the Docker image is automatically found, thus
removing the need to explicitly set it.
If Talkbuchet CLI is executed by other means, or if a remote Selenium
server is used, the browser still needs to be explicitly set.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Firefox requires asynchronous functions to be executed using
"executeAsync", and logs to be got using the BiDi protocol.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
WebDriver BiDi protocol provides bidirectional communication between a
WebDriver client and a web browser. In the original WebDriver protocol
the client sends requests, but the browser is not able to send requests
to the client on its own. Therefore, if a log was written by the browser
the browser could not notify the client, and the client will not notice
the log until it explicitly performs a new request. With the BiDi
protocol the client can subscribe to events in the browser, so the
browser will send them as soon as they happen.
A new helper class is introduced to get browser logs using the BiDi
protocol. Objects of this helper class will start their own thread to
ensure that the logs can be received as soon as they happen, as the main
Python thread could be be blocked waiting while a script is being
executed in the browser and that script can cause log messages to be
printed.
Unfortunately, Chromium does not implement yet getting the logs using
the BiDi protocol, so they still need to be got in the old way. Firefox,
on the other hand, only allows getting the logs through BiDi, so the
BiDi helper introduced here will be required to add support for Firefox.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Executing "await someFunctionCall()" as synchronous code works as
expected in Chromium (the execution will not return until the awaited
function ended). However, it does not when explicit Promises are used
(it returns as soon as the main code finished, without waiting for the
Promise to be fulfilled).
WebDriver provides an explicit way to execute asynchronous functions and
signal when they finished to return, so this is used now for all
asynchronous code.
This will also make possible to add support for Firefox, as in Firefox
asynchronous functions executed as synchronous return immediately, so
they need to be explicitly executed as asynchronous.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Talkbuchet is a JavaScript script meant to be loaded and run in a
browser. However, until now that required manually copying and pasting
the script in a browser console. This commit adds a Python script that
uses Selenium to launch a new browser, load Talkbuchet in it and control
it through the Python script.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
