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:

```sh
$ 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!!