Index

  1. Overview

  2. Architecture

  3. Framework Components

  4. Supporting Packages

  5. Framework Workflow

  6. Execution Guide

  7. Installation Guide

Overview

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, Nunit to further strengthen the capabilities that it renders to the users.

Architecture

Framework Components

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 C#’s .runsettings file. All parameters related to remote platform as “Browserstack” are also configured in .runsettings file.

Relative path of this file is ‘CSharp-Automation-Framework/. Using .runsettings, the user has to select the environment where test execution has to be performed.

All configuration data and its value.

Configuration Data

Value

Description

Platform parameter

web/mobile

This has to be provided in .runsettings 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

https://hub.browserstack.com/wd/hub/

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 customizable. It has been referenced in the ‘/Readers/Excel/ObjRepReader.cs’ file. 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’ . The name and path are customizable and referred in the ‘/Readers/Excel/TestSuiteReader’ file.

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

C# class name along with package full name

Status

Either ‘Run’ or ‘No’

DATASHEET - PROJECT

DATASHEET - TESTCASE DETAILS

TestRunner

It is main script that triggers the test execution and have name it as ‘TestRunner.cs. 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.

Supporting Packages

Drivers

There are two driver files BrowserDriver.cs and BrowserStackDriver.cs which contains WebDriver initialization according to the browser option and execution type in .runsettings file and loading test data specific to test case. In case of execution type as remote, all the browserstack configurations are done from BrowserStackDriver.cs file

TestSuite

This framework utilizes Nunit 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 the browser option in .runsettings file. Each test case or class file should extend TestRunner.cs 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 in ObjRepReader.cs file and test case properties like id, name, status, description is used in TestSuiteReader.cs file.

.runsettings

. runsettings 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 .runsettings file.

Excel

Excel package contains classes that contain methods to read data from excel file. ObjRepReader.cs 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. TestSuiteReader.cs file read data from Suite.xls file which contains all test data specific to various test scenarios have been stored in the datasheet.

Allure Reports

The allure reports configurations and methods are used to generate allure reports into the framework.

Framework Workflow

Execution Guide

https://help.testlio.com/en/articles/6883879-selenium-c-hybrid-framework-execution-guide

Installation Guide

https://help.testlio.com/en/articles/6883764-selenium-c-hybrid-framework-installation-guide

Did this answer your question?