# Introduction

An automation CLI tool that creates the tests project for the Web, the API & the Mobile (iOS & Android) App / Browser. Runs various things like GeckoDriver, ChromeDriver & Appium internally for various stacks, browsers & modes.

# Features

Supports Web App Testing
Supports API Testing with option to store things like token to use them in other APIs
Supports iOS & Android Mobile App Testing
Supports iOS & Android Mobile Browser Testing
Supports Browser Stack cloud environment for Web & Mobile Testing
CLI command to create the boilerplate run the test cases check the appium's necessary & optional dependencies on the system upload the mobile APK or IPA to the browser-stack cloud

# Prerequisite

# Installation

$ npm install -g ga-wdio

# Web Architecture

Boiler Plate Design

The design contains conf/ which contains configuration files for running the tests accroding to usage i.e. in cloud or local browsers.
src/ folder is the main folder where the project's source files are located, which contains subfolders.
storage/ folder contains video, screenshots and log files which are generated according to sessionId(storage folder is generated only after a test has been runned).

Folder Structure

├── conf
│   ├── browser-stack.conf.js
│   ├── chrome-headless.conf.js
│   ├── chrome.conf.js
│   ├── gecko-headless.conf.js
│   ├── gecko.conf.js
│   └── local.conf.js
├── src
│   ├── commons
│   ├── repo
│   ├── tests
│   ├── vendor
│   └── xpaths
└── storage
    └── session_<Session-Number>

Getting to know more about the folders / files

Based on Page Object Model, meaning it is based on page by page test execution & therefore we have divided things into sub-folders for easy test management.

conf/
- browser-stack.conf.js works for BrowserStack cloud platform
- chrome.conf.js works within the local environment on chrome browser
- gecko.conf.js works within the local environment on firefox browser
- chrome-headless.conf.js works within the local environment on chrome browser but in headless mode
- gecko-headless.conf.js works within the local environment on firefox browser but in headless mode

src/
- commons/ contains all the common components / functionality which are present in an application such as Login, etc
- repo/ contains all the components / functionality which are application specific such as filling a form or downloading a file.
- tests/ contains the folders/files where we actually write the test scripts which is based on "Mocha" as a BDD (Behaviour driven development) testing by describing the suite and the test case for that suite.
- vendor/ contains file, if we have to add/use some 3rd party tool.
- xpaths/ contains the locator of element(s) which is defined within a JSON file according to different pages in an application.

storage/
- Storage folder contains sessions folder. These session folders will contain logs, screenshots & screen-recordings generated from your tests.

# API Architecture

Boiler Plate Design

The design contains /src/ which contains all the necessary files for the boilerplate, and this folder contains directories like constants, containers & libraries.
src/api.js file is the main app our runner looks for fetching all the necessary configurations & list of API(s) details.
src/constants/ folder is the main folder where the project's source configurations are located.
src/containers/ folder keeps containers, meaning all of the APIs.
src/libraries/ folder will have all the helper modules & store details files.

Folder Structure

└── src
  ├── constants
  │   └── index.js
  ├── containers
  │   └── employee (sample)
  │   		├── index.js (sample)
  │   		├── list.js (sample)
  │   		└── single.js (sample)
  ├── libraries
  │   └── store.js
  └── api.js

Getting to know more about the folders / files

Based on API Object Model, meaning it is based on API by API test execution & therefore we have divided things into sub-folders for easy test management.

# src/api.js: The API needs two details to execute the tests, and those are domains & apis whereas the store is optional index.

Domains object is actually a key-value paired, where we require default index & you can add more indexes into the same object

api.domains = {
  default: "https://geekyants.com/", // DEFAULT index is REQUIRED!
  download: "https://dl.geekyants.com/" // OPTIONAL indexes...
};

Apis requires an Array of API container modules that would be tested, and the sequence of apis given would be the sequence of their execution.
```
api.apis = [
  require("path/to/containers/api"),
  require("path/to/containers/api")
];
```

Store

// How it works?  	
// Step #1: Create a Store (Object returning file if not exists)

// Step #2: Register store into the api.js file
api.store = {
  token: undefined // undefined is just a default value!
};

// Step #3: Capture the variable (for eg. token) from response's body
expected.store = {
  token: "body.data.jwtToken"
};

// Step #4: How to use the store variable now?
//
// I am using the token in the headers of index API below & to access
// that token you have to use special syntax ie. [<index-name>].
// Note: token is same as given in the Step #2 while registering the API app.
index.headers = {
  "Content-Type": "application/json",
  "Authorization":  "Bearer [token]"
};

# src/containers/your-api-name.js:

Index	Is Required	Comment
name	No	Name of your API, just for the reporting purpose
domain	No	Domain for your API, incase you don't provide this index we will use the default domain given in api.domains
uri	Yes	URI for the API request
method	Yes	The HTTP protocol method for the API
query	No	Can be used only with the GET/HEAD method request
body	No	Can be used only with the POST/PUT/PATCH method request
timeout	No	Max API request timeout
headers	No	Request headers that would override our default request headers
expected	No	To check the response with the expected set of rules
expected.headers	No	To check the response's headers & their value
expected.body	No	To check the response's body indexes
expected.store	No	To store something from the response's body into the store that you can use in other API

# Mobile Architecture

Boiler Plate Design

The design contains /src/ which contains all the necessary files for the boilerplate, and this folder contains directories like common, helpers, test & xpath.
src/common directory contains all the logic that is requires for a specific component or page.
src/helpers directory contains reusable functions / modules.
src/test directory contains all the test cases.
src/xpath directory contains the xpaths for the different kinds of platform & this is why we have added three more directories into it.
We have also added the xpath function in which will return the function depending on the driver type from your xpath sub-directories.
- src/xpath/web contains the web xpaths
- src/xpath/ios contains the ios xpaths
- src/xpath/android contains the android xpaths

Folder Structure

├── conf
├── src
│   ├── common
│   ├── helpers
│   ├── test
│   └── xpath
│      ├── android
│      ├── ios
│      ├── web
│      └── index.js
├── store
└── .env

# Create Command

$ ga-wdio create --help
# Usage: create [options]

# Creates the boilerplate in the present directory

# Options:
#  -h, --help  output usage information

# Examples:
#  ga-wdio create

# Run Command

For Web

$ ga-wdio run:web --help
# Usage: run [options]

# Runs the testing scripts with the options / stacks specified

# Options:
#  -s, --stack <local> <browser-stack> <browser-stack-local>  runs your tests on the local system or browser-stack (default: "local")
#  -b, --browser <chrome> <firefox>                           web browser [chrome or firefox] (default: "chrome")
#  -m, --mode [headless]                                      sets the mode to run web-browser [for local only] (default: "head")
#  -h, --help                                                 output usage information

# Examples:
#  ga-wdio run . 							# Imp Note: This command will set all the default values
#  ga-wdio run --stack=local --browser=chrome --mode=headless
#  ga-wdio run --stack=browser-stack --browser=firefox

For API

$ ga-wdio run:api --help
# Usage: run:api [options]

# [For API] Runs the testing scripts with the options specified

# Options:
#   -h, --help  output usage information

# Examples:
#   ga-wdio run:api

For iOS Mobile

$ ga-wdio run:ios --help
# Usage: run:ios [options]

# [For Mobile] Runs the testing scripts on iOS platform

# Options:
#  -b, --browser <true>                               enables the mobile's browser testing (default: "false")
#  -s, --stack <browser-stack>                        runs your tests on environments like browser-stack/local simulator
#  -h, --help                                         output usage information

# Examples:
#   ga-wdio run:ios # Imp Note: This command will set all the default values
#   ga-wdio run:ios --browser=true
#   ga-wdio run:ios --stack=browser-stack

For Android Mobile

$ ga-wdio run:android --help
# Usage: run:android [options]

# [For Mobile] Runs the testing scripts on Android platform

# Options:
#   -b, --browser <true>         enables the mobile's browser testing (default: "false")
#   -s, --stack <browser-stack>  runs your tests on environments like browser-stack or local simulator (default: "local")
#   -h, --help                   output usage information

# Examples:
#   ga-wdio run:android # Imp Note: This command will set all the default values
#   ga-wdio run:android --browser=true
#   ga-wdio run:android --stack=browser-stack

# Check Command

$ ga-wdio check:appium --help
# Usage: check:appium [options]

# [For Mobile] Checks the necessary & optional dependencies for appium

# Options:
#   -h, --help  output usage information

# Upload Command

$ ga-wdio upload:app --help
# Usage: upload:app [options]
# Returns: app_url, custom_id & shareable_id

# Uploads IPA or APK file to browser stack & returns the app url with custom ID

# Options:
#   -f, --file </path/to/file>  runs your tests on the local system or browser-stack
#   -u, --username <username>   browser-stack username
#   -p, --password <password>   browser-stack password
#   -c, --customId <MyApp>      your custom ID for the app
#   -h, --help                  output usage information

# Examples:
#   ga-wdio upload:app --file=/path/to/file --username=faizahmed --password=somethingsecret --customId=MyApp

# Support

License

GA WDIO is MIT licensed, as found in the LICENSE file.

Supported Versions

Version currently being supported with security updates.

Version	Supported
1.3.4	✔
<= 1.3.3	✖️

Reporting a Vulnerability

To create a vulnerability report please use the common issues template & if you want to reach out to me directly please feel to contact me @ faiz@geekyants.com.

GA-WDIO

# Introduction

# Features

# Prerequisite

# Installation

# Web Architecture

Boiler Plate Design

Folder Structure

Getting to know more about the folders / files

# API Architecture

Boiler Plate Design

Folder Structure

Getting to know more about the folders / files

# Mobile Architecture

Boiler Plate Design

Folder Structure

# Create Command

# Run Command

For Web

For API

For iOS Mobile

For Android Mobile

# Check Command

# Upload Command

# Support

License

Supported Versions

Reporting a Vulnerability