Skip to main content
Playwright Framework User Guide

User Guide for Playwright Framework

Doris Sooläte avatar
Written by Doris Sooläte
Updated this week

Index

This Framework has been designed using test driven development for end-to-end testing. With Playwright we get multiple tools in one. There is no need to install 10 separate tools and libraries to get your test suite set up. Playwright 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.

All configuration related to Playwright is stored in “package.json” file. Below is a list of options and their default values.

Configuration Data

Value

Description

specPattern

./Playwright-Automation/tests/MasterSuite.ts

A String or Array of glob patterns of the test files to load.

Local Browser

Chrome/Firefox

To specify in which browser we want to test the application test.

Playwright Framework is integrated with LambdaTest that will allow to perform Playwright 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 Playwright_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.

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 ‘Playwright-Automation/src/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

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 ‘Playwright-automation/src/excelReader/TestCaseDataReader.ts’ and ‘Playwright-automation /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

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.

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.

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”.

Playwright 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.

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.

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.

Did this answer your question?