Getting Started

Setting up work environment

After installing the tools and running a successful sample run, you can set up the work environment in order to have an organized code base.

Naming convention

Naming folders and files in a similar pattern will help the development become much easier to understand. here are the suggested naming conventions for wdio:

• Folder names: sample-folder-name
• Feature files: sample-test.feature
• Page objects: sample-test.page.ts
• Step definitions: sample-test.ts

Notice how the name (sample-test) is similar in all files and the only difference are their file extension, this will help us to track what files are connected to each other.

Organizing folder structure

First is to organize the folders. the default folder structure is like this:

This folder structure will be harder to organize once the project becomes bigger. In order to create an environment that is easier to handle, separate the feature folder, page-objects folder, and step-definitions folder. here is an example:

In the photo above, the folders are separated but are still inside a new folder called wdio-test, this folder will be the main access to our codes. When the project becomes bigger and we have to create other folders that are not directly part of code like config files, we can then create new folders outside wdio-test.

After organizing the folders, Don't forget to edit the folder paths in wdio.config.ts. if you forget to change that, your code will not run. First is to edit the spec for feature files:

Second is to edit the cucumberOpts for step definition path:

After setting up all of these, try to run the sample test again to test if the new setup works.

Environment Variables

Using environment variables will make the code much easier to configure.

First step is to install the env-cmd package npm install env-cmd --save-dev for more information you can check: https://www.npmjs.com/package/env-cmd

Notice how the env-cmd is added in the package.json. this is because of the --save-dev flag. whenever you install a new package, make sure to add --save-dev flag in order to save it in the package.json

Second step is to create a new file called .env and input the variables you want to set. sample here are the variables from sample test feature file:

The feature step is also modified to remove the variable from the feature since we will access the one in the .env

Third step is to change the step-definition to match the new feature file:

Fourth step is to change the function in the page-object to use the environment variable. you can call the environment variable using process.env.VARIABLE_NAME

Last step is to create a command in the package.json and use env-cmd:

in the photo above, you will notice that the first command in the script is the default command and the second one uses the env-cmd

now you can run the new test by running npm run envtest

Create test typescript file

Creating test typescript file will help you experiment with typescript codes. this file will be ignored in the github releases so you should input the file in the .gitignore

First step is to just create a new typescript file with name typescript-test.ts inside the file input a sample code console.log('this is typescript sample file') also add a new script in the package.json "test-typescript": "env-cmd npx ts-node typescript-test.ts"

In order to run the command, remove the line of code in the package.json as indicated in the photo above. Note that this is temporary only. put back the code in order to run the other tests

Using Tags

To select which tests will be included in the run, you can use tags. in the feature file just put @tagname with tagname replaced by any tags you want

After putting the tag in the feature file, create a new command to run the tagged feature, here is a sample script: "sampletag": "env-cmd wdio run ./wdio.conf.ts --cucumberOpts.tagExpression='@sampletag'"

now try running the tagged feature by running npm run sampletag

Development Flow

Development flow for webdriverio typescript will be the following order:

1. Prepare test case (Jira test ticket or similar)
2. Create new github branch
3. Create feature file
4. Use cuke extension to generate and copy test step
5. Create step-definition file
6. Paste the generated test step and clean the code (add async, add variables if needed)
7. Create page object
8. Get element xpaths needed
9. Create functions in the page object to execute command
10. Call the functions in the step-definition file
11. Run the code

Setting Up Headless Option

Headless setup is needed to test the script without opening a browser. This will be useful for large scale tests like regression.

To setup the headless option, first we need to add the headless variable in the environment file. Its default value will be N which means the test will open a browser every run.

Next is to add the constant variable in the wdio.conf.ts file to instantiate the variable every run.

Then add the following code in the capabilities:

    browserName: 'chrome',
    "goog:chromeOptions": {
        args: HEADLESS === 'Y' ? [
            "--disabled-web-security", 
            "--headless", 
            "--disable-dev-shm-usage",
            "--no-sandbox",
            "--window-size=1920,1080"
        ] : []
    },
    acceptInsecureCerts: true,
    timeouts: {
        implicit: 10000,
        pageLoad: 20000,
        script: 30000
    }

Setting Up Log Level

Log level is also needed to be added in the environment variables as we might need different log levels depending on test runs (local or CI).

To setup the log level, add the DEBUG variable in the .env file. the default value will be Y which means that the log level will be DEBUG if we set the value to N then the log level should be ERROR to minimize the logs to just errors and spec result.

Then add the constant to the wdio.conf.ts

And just change the log level to the variable