kaodimwebdriverioframework v1.0.2

Kaodim WebDriverIO Framework

Installation

Install the latest version of Node.js on your system.

Clone the project and run the following command in the root directory of the project:

$ npm install

This installs all project dependencies

Configuration

Tests are defined to be run from the tests directory. Project specifications and definitions are found inside the config file (wdio.conf.js)

    specs: [
        './tests/*.js'
    ]

Page object definitions also exists inside the config file. All files, defining components to be tested, should end with the suffix shown below:

    exclude: [
         './pageObjects/*_Page.js'
    ]

Page object files are excluded from the test but are imported from and instantiated (as they contain classes) from the test files.

Development

All commands can be found in the package.json. The most important are:

To Run tests:

$ npm test

frameworkUpdate

kaodimWebdriverIOFramework

QA Automation Framework - Selenium WebdriverIO Mocha Based Framework for Kaodim web and apps

Have made changes on the framework to drive the testing based on a config file

Advantages of the config file driven testing: All the configurations related to environment(alpha, beta, omega), country, apps (ios/android/web), and also CI can be configured at one place which would help multiple configs at different places(can be painful and also may lose track).

Somethings which needs attention: I have made use of babel js compiler to achieve backward compatibility of JS with browsers
Using chance library for random variable generation common-errors library to enable configuring all errors at a single place dotenv library to enable working with config files

How to use the config file and how does the framework actually work - A brief insight We have a .env file which is our config file This file has many keywords or environment variable like what it is popularly called. Each of these keywords can be set to various pre-listed/agreed possible values to make our test runner run those particular scenarios in a way which the tester intends it to. .env.example is the template which actually be updated and pushed to master(github) when there is need and .env is for local use. environment.js has the default configuration values for all the env variables which will be used by files in the framework src directory serves as the main directory for the framework scripts below is the new folder structure cfg --> has the capabilities for all the clients (chrome, android, ios, ie, safari, firefox) features --> Is where the features file will reside. Format for naming a feature file is feature name.feature for instance auth.feature step-definitions --> This is where the steps for the feature scenarios reside. The naming convention followed for a steps file is featureName-steps.js for example auth-steps.js support directory holds page objects and all supporting util files for script implementation. here we have subfolders based on the platforms(android, ios, web) of execution. I have made use of appFactory to direct the cases for each execution to the proper platform files. app.js and app-factory.js helps here And the platform specific pages reside inside the respective platform subfolders screen.js is the basepage for all web screens/pages which will be used for common functions, also can include common elements if present across multiple pages.

Hope this notes helps with a basic understanding of the framework change and the framework itself helps us with a scalable and maintainable design.

Happy coding!!