Playwright UI Testing

What is Playwright?

Playwright is a test automation library. It allows us to create tests that cover how the application should always behave. It is mostly used in regression testing i.e we write tests and if they fail then the team will decide if the original application has regressed or whether the test just needs to be updated. Playwright mainly runs on 3 default browsers Chrome, Firefox and Webkit (Safari) There are also options to run the same browsers on mobile viewports.

How does it work?

A basic Playwright UI test will navigate to the specified page and carry out various actions or user flows. Then an assertion will be made at the end of the test. If there are 10 things that the application must always do, then a test suite can take care of it automatically: by either running it on the new feature branch or actually having it as part of a CI/CD pipeline. This means that any system regressions can be caught swiftly.

API mocking

Playwright also provides API Mocking functionality. By mocking the API response, we make sure to use the same data each time. This is useful as it becomes increasingly difficult to write tests for data that is always changing. Mocking makes it easier to write tests as you are always expecting the same data, making it straight forward to write assertions against it.

We have efficiently mocked object data using partially overridden interfaces. Which allows us to have default object and then only change what we need in the specific test. See -> vAirify\air-quality-ui\system_tests\utils\mocked_api.ts

The Page Object Model

In a typical Playwright test we will have the test itself locating the page elements in various ways. e.g. by role, label or text. Locators We have used the "Page Object Model" design pattern in which we create classes for pages and components. This means that we have all of our actual test logic inside those models and simply call the methods into our tests. Pros

• Reduces repetition.
• Cleans up test files to only actually setup assertion data and assertion action
• If an element is changed in some way, then all we have to do is update the locators in the page object model (this saves us from having to manually edit many tests)
• If the functionality somehow changes, all we have to do is change some of the functional logic within the page object and the actual tests can stay untouched.
• Tests have improved readability

Structure

Here is the folder structure for playwright ui/e2e tests.

These tests navigate through the application invoking many different methods and functions. Ideally tests will cover the "Happy path" and the "Unhappy Path": What should happen ideally and what shouldn't happen. An example of a happy path is "As a user I open up the application and I should see a grid of many cities with pollutant information. An unhappy path could be, "If I try to search for a city that doesn't exist then I should be met with a clear error message".

Pages - They don't necessarily have to be "Pages" They can also be components like the banner. We write methods that are specific to the page/component in here.

UI - Tests are mainly focusing on how things should look as opposed to what should happen. For example, a test that cycles through each of the grid cells and returns an array. By looking at the data you have mocked as a tester you should be able to create another array of how you expect the data to look. Then a test can be written to compare both arrays.

Utils - These are just various files to help out with mocking and methods that are more generalised. Meaning that they don't exactly fit into a page object model of any sort.