Support & information center

The test’s web browsing flow is defined as a Nightwatch/Selenium test case. Nightwatch.js enables quick, simple but powerful tests writing, using only Javascript (Node.js) and CSS or Xpath selectors. Nightwatch.js uses the powerful Selenium WebDriver API to perform commands and assertions on DOM elements. For further information about Nightwatch, please refer to http://nightwatchjs.org.

Our goal is to enable you to focus on your core logic. Therefore, testRTC takes care of the script’s generic and infrastructure parts, such as the script’s initialization and objects creation.

You should focus only on the script logic to test your service.

Function types

In the test scripts we use functions and commands from the following groups:

• Nightwatch/Selenium commands – the Nightwatch/Selenium commands handle all browsing related actions, such as navigating to specific web pages, clicking on buttons and screen artifacts, filling in form fields, etc. Detailed Nightwatch/Selenium API reference can be found in http://nightwatchjs.org/api#commands
• testRTC functions – testRTC functions were implemented in order to help you debug your service. testRTC functions supports actions such as take a screen shot and create a log message. Check out or list of WebRTC-specific script commands
• Javascript – Javascript types, operators, objects and methods can be used in the script

Chaining commands

The client object that appear at the beginning of the script handles all Nightwatch/Selenium browsing related actions, such as navigating to specific web pages, clicking on buttons and screen artifacts, filling in form fields, etc.

All functions in the script return the client object and therefore a common method to scripts writing is chaining commands. When chaining commands, there is no need to add the semicolon symbol at the end of every command.

For example:

client
   .url()
   .setValue()
   .rtcScreenshot()
   .click()Code language: CSS (css)

General flow

In general, most of the scripts will be based on the following flow:

1. Navigate to the service web page
2. If needed, enter some details (e.g. for video chat room, type user name and password to login)
3. Click on a button to join a WebRTC session. At this point, the video call page should be loaded. As part of the video call page, the browser will be requested to stream the camera and microphone to the other parties in the call. When the camera and microphone streaming will be requested, testRTC will stream the selected video and audio media, instead the machine’s camera and microphone
4. Consume media. Ensure to consume the media for enough time so testRTC system will be able to collect enough QoS information
5. If needed, perform activities during the session, such as enter chat messages. In any case, we need to keep the test running for the requested time period. It can be done by using the pause command
6. The total script duration will actually set the test’s total duration
7. Test end / Session stop: While a WebRTC session is active, the browser collects statistical information that we will parse in order to present the test results, calculate test expectations, etc.  If the browser will surf to a new URL, the browser will clear the WebRTC statistics and we will not be able to collect this information at the end of the test. Therefore please ensure that you will not surf to a new URL at the end of the WebRTC session

Note that in many implementations, terminating a session will redirect the browser to a new URL. In such cases, please refrain from terminating the session. The session will be killed after we will collect the data and we will delete the instance that executed the test. For further information, please see here.

Single script, multiple probes

In testRTC, each test is executed using a single test scripts that gets executed by multiple probes (=browsers) simultaneously.

For tests that are symmetric in nature, where all probes need to perform the same actions, this is great.

If you need to create asymmetric tests, where different probes run different logic (such as instructor/students or joining different rooms), then this can be achieved by using the environment variables. For example, variables such as process.env.RTC_IN_SESSION_ID along with if statements are quite useful in providing different flows for instructors and students joining the same room.