Index
This Framework has been designed using hybrid driven approach by bringing together Data Driven and Keyword Driven concepts to have more efficient framework that will be suitable to automate all web applications that are data intensive or containing unique workflows. It has been integrated with other tools like Appium, unittest to further strengthen the capabilities that it renders to the users.
Hybrid Driven Framework
Environment Data
All data related to test environment like platform, browser, remote platform, parameters used by test at run time etc. will be provided in config.ini file. All parameters related to remote platform as “Browserstack” are also configured in config.ini file.
All configuration data and its value.
Configuration Data | Value | Description |
Platform parameter | web/mobile | This has to be provided in config.ini file to specify the platform on which test has to be run. |
Execution Type | local/remote | For local execution of tests write value as local and for remote execution of tests on azure/browserstack/headspin, write value as remote |
Local Browser | Chrome/Firefox | To Specify in which browser we want to test the application |
Remote Platform | Azure/browserstack/ /headspin | To Specify in which remote platform we want to test the application |
browserstack-uri | This must be provided to specify browserstack url to run the tests on browserstack | |
browserstack-browser-name | Chrome | This must be provided to specify browsername to run the tests on browserstack |
browserstack-browser-version | < browserstack-browser-version > | This must be provided to specify browser version to run the tests on browserstack |
browserstack-os-name | < browserstack-os-name > | This must be provided to specify browserstack OS name to run the tests on browserstack |
browserstack-os-version | < browserstack-os-version > | This must be provided to specify browserstack OS version to run the tests on browserstack |
browserstack-username | < browserstack-username > | This must be provided to specify browserstack username to run the tests on browserstack |
browserstack-access-key | < browserstack-access-key > | This must be provided to specify browserstack password to run the tests on browserstack |
browserstack-build-name | < browserstack-build-name > | This must be provided to specify browserstack build name to run the tests on browserstack |
Object Repository
It is a collection of objects and its properties by which a test automation tool will be able to identify the objects in the application. All the objects are stored in the spreadsheet and named as ‘AppObjectRepository.xls’ and indeed the name is customisable. Separate sheets are maintained for storing object properties from different application screens. Say, for an application consisting of five screens can have the properties stored in five sheets,
Column Name | Purpose |
Element Name | Any unique name to represent application object, suggested standard to follow –<ScreenName_FrameType_ObjectType_Name> |
Element Type | Locator Type Identified by tools say xpath,className, linkText |
Value | Object properties recognized by locator type |
Datasheet
All test data specific to various test scenarios have been stored in the datasheet. File format used for storing this information is excel spreadsheet and named as ‘suite.xls’ .
It contains two categories - List of modules/projects have been listed under ‘project’ sheet and test scenarios corresponding to each module/project are maintained in separate sheets with same name. Say for an application consisting for three modules will have one ‘project’ sheet and ‘three’ separate sheet containing test case details. In Order to execute the test cases in the module, user must update it to ‘Run' mode in project and test case sheet. Test data/parameters are added as columns in test case details sheet. Following are the mandatory fields.
Column Name | Value |
TCID | Numeric and Unique |
Test Case | Python class name along with package full name |
Status | Either ‘Run’ or ‘No’ |
DATASHEET - TESTCASE DETAILS
TestRunner
It is main script that triggers the test execution and have name it as ‘suite_runner.py. It loads all objects properties from object repository sheet, modules and corresponding test cases to be executed from the data sheet based on ‘Run’ Mode. Tests need to implement this runner and get access to object repository. User has to always start running the script from here.
Drivers
There are driver files driver_factory which contains WebDriver initialization according to the browser option and execution type in config.ini file and loading test data specific to test case. In case of execution type as remote, all the browserstack configurations are done from page factory file
Pages and TestCases
This framework utilizes unittest Framework capabilities of Annotations to perform initialization/pre-requisite setup or termination/post-execution activities. Usage of Annotations is a way to define the order and any dependency of execution. Some of them are WebDriver initialization according to test browser option in config.ini file. Each test case or class file should extend suite_runner.py file in order to utilize complete built-up feature and loads all objects properties from object repository sheet.
Selenium Wrapper
Selenium related methods have been generalized by and have been grouped under this package. User can a call to the methods directly and built-in validations reports the results accordingly. Say OpenUrl, Click, isElementPresent, initializing browser driver, etc.
Entities
Locator and Test case parameter initialization has been grouped under entities. Locator type and value is used app_objects_reader.py file and test case properties like id, name, status, description is used in Test_case_reader.py file.
Conig.ini
Conig.ini files has the environment and execution properties for the test. All data related to test environment like platform, browser, remote platform, parameters used by test at run time etc. will be provided in this file. All parameters related to remote platform as “Browserstack” are also configured in config.ini file.
Excel
Excel package contains classes that contain methods to read data from excel file. app_objects_reader .py read data from AppObjectsRepository.xls file which is the collection of objects and its properties by which a test automation tool will be able to identify the objects in the application. Test_case_reader.py file read data from Suite.xls file which contains all test data specific to various test scenarios have been stored in the datasheet.
HTML Reports:
The HTML reports configurations and methods are used to generate allure reports into the framework.
