Nautical Poseidon Mythology

    TypeScript icon, indicating that this package has built-in type declarations

    3.0.23 • Public • Published

    WebdriverIO + Allure reporter + TypeScript

    Build Status Open issues Version

    Util that blends WebdriverIO , TypeScript and Allure Reporter in to end-to-end UI testing solution. It wraps the most common WebdriverIO actions, generating intuitive error messages in case of failure, custom logs for the Allure Reporter, more validations for enhanced stability, and last, but not least, IntelliSense.

    Getting Started

    You need to install Java JDK 8 or above, NodeJS

    Supported browsers Chrome


    Install this package together with helper packages

    npm i -D wdio-allure-ts typescript start-server-and-test chai http-server

    Getting Chromedriver version

    node lib/scripts/GetChromeDriverVersion.js

    Setting last Chromedriver version to .env file

    yarn setChromeDriverVersion

    Add example test

    See TestHelper used in the example below

    // specs/example_test.spec.ts
    import { expect } from 'chai';
    import { describeCommon } from '../TestHelper';
    import { BrowserUtils } from 'wdio-allure-ts';
    const { click, getAttribute, isDisplayed, waitForDisplayed, waitUntil } = BrowserUtils;
    const getImgSrc = () => getAttribute('#myimage', 'src');
    describeCommon('Test Example', () => {
      beforeEach(() => {
        // runs before each test in the block
        click('#displayImage'); //for example
        waitForDisplayed('#myimage'); //for example
      it('Should display the image', () => {
      it('Image should have some src eventually', () => {
        const testImgSrc = () => getImgSrc() === '';
        waitUntil(testImgSrc, 'Error message for failing test', 2000);

    Add tsconfig.json

      "include": [

    Add scripts to package.json

    • start-server-and-test will serve the test app, wait max of defined timeout for the test app to be available at, and then run the test script.

    See wdio.conf.js for example configuration of WebdriverIO

      "scripts": {
        "test": "npm run setChromeDriverVersion && tsc && wdio ./wdio.conf.js",
        "serve": "http-server",
        "start-server-and-test:mytest": "WAIT_ON_TIMEOUT=600000 start-server-and-test serve test"

    Run tests

    npm run start-server-and-test:mytest


    Install and run tests

    yarn install all dependencies

    yarn start:sampleApp spin up the sample app page for testing

    yarn test execute all tests

    yarn spec <spec name> to execute specific spec file

    Environment variables

    PRINT_LOGS_TO_CONSOLE - false by default. only enabled in dev configuration, since parallel tests execution will log to same terminal

    DEFAULT_TIME_OUT - timeout for webdriverIO actions. Default value 60 seconds

    CHROME_DRIVER_VERSION- version of chromedriver

    Project Structure


    Logs to both terminal and allure report


    webdriverIO actions wrapper


    Common utils for tests such as getRandomString()


    Holds keyboard special keys


    Common utils for git like get the last merged files


    Common utils for testrail api like update tests field

    Example for TestRailUtils

    //Update the Automation field for the last merged tests to Automated

    try {
      const lastMergedTestsIds = GitUtils.getLastMergedTestsIds();
    } catch (error) {

    Example With Pure WebdriverIO

    Now take a look at an example of an action that, after validating that a particular element is visible, clicks it, logs every step to the Reporter, and throws meaningful errors for failures, if any.

    const selector: string = 'someSelector';
    logger(`Click an element with selector: ${selector}`);
    try {
      logger(`Validate element with selector ${selector} is displayed`);
    } catch (error) {
      throw new Error(`Tried to click not visible element, ${error}`);
    try {
      logger('Perform click action');;
    } catch (error) {
      throw new Error(`Failed to click an element by given selector ${selector}. ${error}`);

    Example with wdio-allure-ts:

    const selector: string = 'someSelector';;

    You can see that wdio-allure-ts offers the same capabilities with much cleaner code. Because it automatically handles logging and error reporting, developers can focus on testing the business logic. You can add more report logs with a simple Reporter API for log levels: step, debug, error, info, and warning. The logs are displayed on the terminal and reflected in the report. Example:

    import { Reporter } from 'wdio-allure-ts';
    Reporter.step('Step log entry');
    Reporter.error('Error log entry');

    Terminal Output

    Terminal Output Note the difference in the highlighted areas between the original report and the one created with wdio-allure-ts. Original Report

    Original Report

    wdio-allure-ts Report(live report example):

    wdio-allure-ts Report

    CLI execution

    Added an option to execute tests with cli.


    node ./lib/helpers/runner.js

    That uses default wdio configuration wdio.default.conf.js if no parameters passed.

    Additional available cli inputs:

    --specs "test1.js" "test2.js - tests path separated by space

    --config "customConfig.js" - path to custom config for wdio execution

    CLI example:

    node ./lib/helpers/runner.js --specs 'specs/TEST1.js' 'specs/TEST2.js' --config 'customConf.js'

    How to write commit message

    We use Conventional Commits For commit message, please use a template:

    <type>[optional scope]: <description>
    [optional body]
    [optional footer(s)]

    We use several types:

    fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning)

    feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning)

    test: a commit of the type test introduces a new test or correcting existing tests (this correlates with MINOR in semantic versioning)

    docs: commit of the type docs introduces adding/fixing documentation (this correlates with MINOR in semantic versioning)

    BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning).

    A BREAKING CHANGE can be part of commits of any type.

    Ready to Try?

    Check out a sample project with a quick introduction to our framework and its usage on a real-world application


    npm i wdio-allure-ts

    DownloadsWeekly Downloads






    Unpacked Size

    132 kB

    Total Files


    Last publish


    • cloudinary