Webdriver.io Overview

Introduction

Check out the Getting Started with Webdriver.io guide for a quick introduction on how to run your test script. Also check out our Selenium overview guide to better understand how Selenium tests run on Testable in general.

This document goes into further detail on the various options provided for running Webdriver.io scenarios in general.

Creating a Scenario

There are two ways to create a Webdriver.io scenario:

  1. Create a new Test Case (Create Test button on the dashboard or Test Cases -> New… on the left nav), select Selenium during step 2.
  2. Go to an existing test case and click on the Scenario tab. Click the New Scenario button and select Selenium as the scenario type.

Run Style

Webdriver.io provides you two options to run your test. Both options are supported on Testable and in both cases you can provide a package.json file that defines all the dependencies of your test.

  1. Configuration File: Provider a wdio.conf.js that defines your test and relies on the wdio test runner to execute it.
  2. As Code: Provide a main js script. The script will run Webdriver.io as code via WebdriverIO.remote() or WebdriverIO.multiremote(). Testable ensures that these API calls will work as expected against a local Selenium server or chromedriver on the test runner.

Read the Webdriver.io documentation for additional information about each option.

Source

There are two ways to load your Webdriver.io scenario into the Testable platform.

  1. Upload Files: Upload the files/folders required to run your Webdriver.io test. Note that if you upload a zip file it can either be unzipped into your scenario or on the test runner before execution.
  2. Version Control: Download the test files from a version control repository. See our version control guide for more details. An example repository can be found at wdio-testable-example.

Webdriver.io Test Runner Configuration

Only applicable if Run Style = Configuration File.

See the wdio-testable-example README file for more details on how to setup your configuration file to be Testable compatible.

Testable APIs: CSVs, metrics, logging, execution info

The testable-utils library provides several Testable APIs for:

  1. Capturing custom metrics
  2. Logging
  3. Execution Info
  4. Reading from a CSV file
  5. Timing code blocks
  6. Live manual events

All these APIs will work when run locally as well

See the testable-utils README for more details.

Screenshots

All screenshots get reported back to the results by default. To only capture a sampling of screenshots toggle the Advanced Options -> Advanced Settings -> Capture All Output box in your configuration.

Custom Resource Names (Configuration File Only)

Test executions have a section that breaks down the results by “resource”. By default the “resource” used for grouping results is the HTTP method (if any) plus the base url plus the first 2 parts of the path.

For example, if the browser downloads an image from URL http://www.mycompany.com/static/images/abc.png, the resource name would be GET http://www.mycompany.com/static/images/....

This is done to avoid too many result groupings that are not useful. Note that Testable limits test results to 600 unique resources after which overall and regional results are still calculated but no new resource groupings are created.

To override the default behavior add a custom toResourceName(url, method) function to your wdio.conf.js configuration file.

wdio.local.js

exports.config = {
  specs: [
    "test.js"
  ],
  ...
  testableOpts: {
    // returns [METHOD] [BASE URL]
    toResourceName: function(url, method) {
      const obj = urlModule.parse(url);
      return (method ? method + ' ' : '') + obj.protocol + '//' + obj.host;
    }
  }
};

There is no equivalent option if you use Run Style = Code. For all scenario types you can choose to change the number or URL parts to capture in your scenario under Advanced Settings => Resource Names.

Browser Logs

We recommend using the wdio getLogs() api to get access to the browser console.

Here is an example where we print the browser logs after each test to the Testable log (make sure to add “lodash”: “4.17.10” to your package.json dependencies):

wdio.conf.js

const _ = require('lodash');

function printLogs(logType) {
  _.forEach(browser.getLogs(logType), function(log) {
    browser.testableLogInfo(`[${logType} log] [${log.level}] ${log.message}`);
  });
}

exports.config = {
  //...
  capabilities: [
    {
      browserName: "chrome",
      "goog:chromeOptions": {
        w3c: false,
      },
      "goog:loggingPrefs": {
        "browser": "ALL"
      }
    }
  ],
  //...
  afterTest: function(test) {
    printLogs('browser');
  }
};