September 1, 2023
Playwright is an open-source development tool that enables testing of web applications on various web browsers, it is a tool that simplifies the entire software delivery process, allowing us to automate testing. It is also a new software released by Microsoft in January 2020, which is now starting to gain popularity. It has many capabilities that can be used, many built-in methods and assertions. Our main goal in this program was to check the consistency of the appearance of the site with the design, where the entire layout is compared, and functional tests are carried out, without any problem such things can be covered with this tool, it also offers us visual regression tests.
Playwright is a very similar tool to Selenium. If you previously used Selenium, you will not have a problem switching from one tool to another. The tool itself is very user-friendly and does not give us a big threshold for entry, although it offers a lot of possibilities. On the positive side, there is comprehensive technical documentation. Just having the option to use a browser such as Webkit where most programs do not support it, and here we have:
Playwright contains a lot of built-in options whereas in other tools you need to use external plug-ins, for example, in Cypress for the hover method you need to download the appropriate plug-in, while in Playwright we do not have such a need. I will also add an option where it is rare visual regression tests that are built-in and are completely free. In other tools to carry out such tests you need to, for example, perform integration with Percy which is paid.
The Playwright tool has been used to improve the quality of our Pathways project, to check if the page view is consistent with the design, and to check functionality. This tool allowed us to automate this process, which speeded up the work and raised the quality of the delivered product to an even higher level.
To use the tool in our project, we first need to install our tool into our repository via the command:
npm init playwright@latest
When installing the project you can choose the programming language you want to use, by default TypeScript is set, and you can name your test folder or choose a default name. When installing browsers, by default true is set, and this option I recommend choosing by default.
Then the basic packages will be installed:
playwright.config.ts
package.json
package-lock.json
tests/
example.spec.ts
tests-examples/
Demo-todo-app.spec.ts
If the tests have already been installed in an existing project, the dependencies will be added directly to your project package.json.
A folder named tests will also be created, which will contain the sample test.
The next step to take in the existing project is to add shortcuts to select elements using specified attributes (an attribute in HTML is part of the syntax of tags used to define and manipulate elements on a web page. Attributes provide additional information about HTML elements and define their properties or behavior).
Currently, Playwright offers us the following attributes:
id
data-testid
data-test-id
data-test
This is a recommended practice, the entire workflow will be streamlined because the name of a given placeholder (A placeholder in the context of software programming and testing is a mechanism or expression that identifies a unique element or set of elements on a web page or in an application. Locators are used to find and interact with user interface elements in automated tests or in programming scripts). It will always be the same and recognized by the data ID, where some selectors are built dynamically, and their names can always change. In this case, such a mistake will not occur with the selector name changing and the given locator will not be found.
The second option is when the project is created anew. The process looks similar, except that test attributes are added on the fly during implementation by the programmer or in cooperation with QA.
Once the test attributes are defined, we can move on to the next step, which is to write the first test. In order to write the first test, you need to start by adding a new file in the test folder:
When creating a new file, remember the correct syntax, e.g. Test1.spec.ts.
The word spec is a key here so that the program knows how to recognize the test file.
We have just written the first test using the hook beforeEach, that is, every time the program goes to the next test we will be redirected to the specified page.
As part of the test, test.describe was used, it contains a description of what will be tested, e.g.
Testing page 1 of the project. Then a test will be added that will, for example, check section No. 1 of this page.
The file contains an import, which is very important for the program to know how to perform tests and assertions, as well as a locator for testing purposes.
In the test, when you go to the page, the title of the page displayed in the browser tab is checked, then it is checked whether the locator is visible on the page.
In the next step, another assertion is made, which checks whether the tenant has the given styles and whether they are as expected.
It is important, before running the first test, to define the URL to be opened in the tests and select the browsers on which the system is to be tested, for the tests set the browser Chromium (Chrome) and was given the address to which the program during the test should go.
In the playwright.config file the URL should be defined in baseURL:
When the baseURL is defined, all you need to do is to apply a slash in page.goto('/'), so that the program knows which URL it should go to.
Then you define the browser that will be used for testing, and in addition, you can set the viewport values according to the requirements of the project.
Such a test file will run tests for the desktop version. To run the first test, you need to remember to start the local environment of the project or provide the URL to the web application where it is available.
The command to run the first test is:
npx playwright test
The test was successfully launched.
The test did not pass because there were found errors. The expected result is different from the current one. As we can see below, Playwright immediately informs about the defects found in the system, in addition, it offers to display the report in HTML form. This is the form set by default:
Below is presented the report in HTML form, which does not mean that we can not do it in other ways.
So we know that the created assertions work correctly, then the code will be corrected so that the result of the test will be positive.
After the changes have been made, the test will be restarted with the command
npx playwright test:
The test ended with a positive result.
In a further stage, the code can be extended with a number of new functions and assertions. It is recommended to use the AAA pattern for this, about which there will be more later in the article.
Playwright supports a number of reporting options. The first and basic of which has already been presented is the HTML reporter option, which is quite transparent and often used in local mode, while in CI/CD Gitlab the junit reporter is used, thanks to which tests, which detect irregularities in the system, inform the user about the faults. To increase the reporter's control, changes can be made to the configuration file, e.g.
Playwright also has options to present reports in a visual form:
You just need to set the trace value appropriately. In the Pathways project, this option is disabled so as not to burden the Gitlab runner with additional data from artifacts created after the test is completed. In contrast, Playwright offers to use this option directly from the console using the command:
npx playwright test --trace on
In traces, there is a recorded file from the tests.
The trace option allows you to trace the entire testing process in visual form, it can also be done in debug mode.
The automation tool was used to automate repetitive processes and read regression tests. The main aspect is UI testing. The program has been used in Gitlab CI/CD, so that with each merge request the developer is informed about the results of the tests, so that the product will be released to the environment in better quality, and thanks to this method the process will be improved in order not to release software that does not meet the requirements.
In the tests that were applied in the Pathways project there are 3 basic patterns that help to maintain quality and order in testing, below are the patterns:
AAA pattern is based on the division of the test into 3 stages:
DRY or more precisely Don't Repeat Yourself is a principle in programming that says not to repeat the same code in different parts of a program.
Instead of repeating the code, you can separate the repetitive parts and put them in one place (file, function, method, etc.). This practice often makes the code easier to understand, easier to make changes, and reduces the risk of making mistakes.
It also saves us time and effort because we don't have to write the same code repeatedly.
POM or more precisely Page Object Model is a design pattern used in test automation. The pattern focuses on separating the logic responsible for interacting with pages into separate modules, which we then use in tests.
POM is based on the representation of the structure of the website under test in the form of classes/objects. Such an object then contains methods that represent the actions a user can perform on the page.
Page Object Model helps to separate test logic from implementation details. As a result, when the application changes, such as the structure of elements on the page, you don't need to modify the test code, only the relevant Page Object objects.
Using the Page Object Model, you can easily and clearly write automated tests that are more resistant to changes in the application and easier to maintain.
An interesting thing that I met and decided to expand is the methods built into Playwright. These are very nice and easy to customize and here's an example below:
.png)
This is an assertion that checks whether a given tenant contains a given style with specific values.
That is, in the assertion above, we check a given locator - font-size = 20px.
But what if for a given tenant we want to check more CSS?
E.g. we have such an object with styles:
.png)
This can be done without any problem and entering values manually into the method offered by Playwright but here the DRY method is bypassed, such code would look like this:
.png)
Assertions have been written which check all available styles for a given tenant, everything is fine, but what if there are more such tenants to cover or a given tenant contains more styles?
In the above example, the data was entered manually, which is the consequence of creating new lines of code, in this case, 5.
So can it be done better?
Of course yes. Here, the help of programming knowledge allows us to write scripts that work well with the methods offered by Playwright.
What if you can make from 5 lines of code only one
And here is an example of how this can be done. First, an object with test data should be created:
.png)
The next step will be to write a function that extends the method offered by Playwright:
.png)
The next step will be to execute the function already in the program. To the function, you should pass 3 parameters page, locator, and test data.
.png)
Thanks to this change, the DRY practice is applied.
A function or method can be extended further if there is more than one placeholder with the same name that contains the styles from testTitle.
A function can be built in two ways, using a simple for loop or the built-in option offered by Playwright.
1 method represents a for loop:
.png)
In the 2nd method, the method offered by Playwright .all()
for (const li of await page.getByRole('listitem').all())
await li.click();
This is a built-in method offered by Playwright for iterating.
Another thing that is useful in this tool is the option to:
const box = await page.getByRole('button').boundingBox();
Thanks to boundingBox the program will display the values of a given tenant, which allows you to check the actual distance of elements from each other that occur in the system.
This method can be extended by custom code, which allows you to check the vertical and horizontal distance of elements next to each other.
.png)
.png)
Using such a code technique, changes to the layout will be immediately detected and the spacing between elements and styles will be checked, and this is only a part of the possibilities and challenges that can be encountered in Playwright. At the moment it is not known whether this program can not do something because the situation has not yet happened.
To sum up, Playwright is a Microsoft tool, using the Visual Studio Code editor, Microsoft offers us a playwright plugin for VSC which makes debugging easier, it is called Playwright Test for VSCode.
The framework was used to cover business requirements from the customer side, so that the whole development team caught defects much earlier, and could spend this time on other things related to the development of the project.
Wojciech Błądek
Playwright - how this tool has affected the quality of the delivered system
%2520(344%25C3%2597234%2520px)%2520(Post%2520na%2520Facebooka%2520(Krajobraz))%2520(2).png)
