Index
This Framework has been designed using test driven development for end-to-end testing. With Cypress we get multiple tools in one. There is no need to install 10 separate tools and libraries to get your test suite set up. Cypress is a next generation front end testing tool built for the modern web. This enables us to write faster, easier and more reliable tests like end-to-end tests, Component tests, Integration tests and Unit tests.
Environment Data
All configuration related to cypress is stored in “cypress.config.ts” file, which is cypress configuration file. The default behavior of Cypress is modified by supplying below configuration options. Below is a list of options and their default values.
Configuration Data | Value | Description |
specPattern | ./cypress/tests/MasterSuite.ts | A String or Array of glob patterns of the test files to load. |
supportFile | ./cypress/support/e2e.js | Path to file to load before spec files load. This file is compiled and bundled. (Pass false to disable) |
pluginFile | ./cypress/plugins/index.js | To provide support for plugin and extend the behavior of Cypress. |
experimentalSessionAndOrigin | true | When experimentalSessionAndOrigin is enabled, Cypress will no longer wait on page loads between hooks before moving on to the next test. |
chromeWebSecurity | false | Whether to enable Chromium-based browser's Web Security for same-origin policy and insecure mixed content. |
pageLoadTimeout | 120000 | Time, in milliseconds, to wait for page transition events or cy.visit(), cy.go(), cy.reload() commands to fire their page load events. Network requests are limited by the underlying operating system, and may still time out if this value is increased. |
numTestsKeptInMemory | 50 | The number of tests for which snapshots and command data are kept in memory. Reduce this number if you are experiencing high memory consumption in your browser during a test run. |
Cypress Framework is integrated with LambdaTest that will allow to perform Cypress Testing across 40+ browser versions on cloud. “Lambdatest-config.json” is provided with configuration for the below fields:
lambdatest_auth - Username and accesskey is defined here.
browsers – Browser details like browsername, platform and browser versions are provided here.
run_settings – Configuration details like cypress_config file name, reporter_config file name, build_name, parallels, specs, network and headless are provided here.
tunnel_settings – Tunnel settings details like tunnel_name and tunnel (true/false) is provided here.
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 ‘cypress/excelReader/AppObjectsReader.ts’ 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 ‘Suites.xls’. The name and path are customizable and referred in the ‘cypress/excelReader/TestCaseDataReader.ts’ and ‘cypress/excelReader/TestReader.ts’ 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 Description | Description of the test |
Test Case | Path of test case with test case 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 “MasterSuite.ts”. 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 must always start running the script from here.
ErrorHandler
All error handling methods to handle exceptions must be included in ErrorHandler.ts. The handlerrors() class should be called before every test case. The errors such as “The user aborted a request” are included in this file.
ExcelReader
This has classes to read data from excel files. The AppObjectsReader.ts file contain methods to read locator name and locator type from the AppObjectRepository.xlsx file. The TestCaseDataReader.ts file contain methods to read username and password from Suites.xlsx file. The TestReader.ts file read data from Suite.xlsx file and has methods to read the project name, run mode and platform. It also contains the methods to read the test case list from the worksheet having run mode as “Run”.
PageFactory
Cypress 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 Scroll, Click, getElement, waitForTimeout, etc.
Pages
Typescript methods to initialize the locators as per page object model are included in the specific ts class. The classes also contain the methods to use the locators and define common functionality like login, sign in, etc.
TestSuite
Test classes are included in Tests package. The tests utilize beforeEach hook which contain repetitive steps i.e. the framework utilizes mocha Framework capabilities of hooks to perform initialization/pre-requisite setup or termination/post-execution activities. Usage of hooks is a way to define the order and any dependency of execution.
