Test.step is a useful feature in Playwright that helps to improve the human readability of test reports by allowing for the breakdown of individual actions within a test and grouping of relevant steps together. This helps to provide a clearer understanding of what is happening within the test and can aid in debugging if an issue arises.
One of the key benefits of test.step is that it updates the test steps section of the report to give a much clearer roadmap of what the test is covering and what steps it failed on. This can be especially helpful in identifying the root cause of a failure and can save time and effort in the debugging process.
Playwright provides APIs to monitor and modify browser network traffic, both HTTP and HTTPS. Any requests that a page does, including XHRs and fetch requests, can be tracked, modified, and handled.
Let’s speed up your Playwright scripts with request interception.
Check out our API mocking guide to learn more about how to
mock API requests and never hit the API
perform the API request and modify the response
use HAR files to mock network requests.
Data-driven
Playwright Test includes the ability to produce and visually compare screenshots using await expect(page).toHaveScreenshot(). On first execution, the Playwright test will generate reference screenshots. Subsequent runs will compare against the reference.
Note: We can use mask, maxdiffpixels, stylepath to achieve the exactly image that we want to compare
Option mask: Locator[] masks given elements, overlaying them with pink #FF00FF boxes.
The playwright executes tests in isolated environments called browser contexts. This isolation model improves reproducibility and prevents cascading test failures. Tests can load existing authenticated states. This eliminates the need to authenticate in every test and speeds up test execution.
https://playwright.dev/docs/auth#basic-shared-account-in-all-tests
https://playwright.dev/docs/auth#authenticate-with-api-request
https://playwright.dev/docs/codegen#preserve-authenticated-state
When to use: You need to test how multiple authenticated roles interact together, in a single test.
Details: Use multiple BrowserContexts and Pages with different storage states in the same test.
By default, failed assertion will terminate test execution. Playwright also supports soft assertions: failed soft assertions do not terminate test execution, but mark the test as failed.
At any point during test execution, you can check whether there were any soft assertion failures:
Note that soft assertions only work with Playwright test runner.
Playwright Test runs tests in parallel. In order to achieve that, it runs several worker processes that run at the same time. By default, test files are run in parallel. Tests in a single file are run in order, in the same worker process.
You can configure tests using test.describe.configure to run tests in a single file in parallel.
You can configure entire projects to have all tests in all files to run in parallel using testProject.fullyParallel or testConfig.fullyParallel.
To disable parallelism limit the number of workers to one.
You can control the number of parallel worker processes and limit the number of failures in the whole test suite for efficiency.
Use test.describe.serial() to group dependent tests to ensure they will always run together and in order. If one of the tests fails, all subsequent tests are skipped. All tests in the group are retried together.
Playwright Trace Viewer is a GUI tool that lets you explore recorded Playwright traces of your tests meaning you can go back and forward through each action of your test and visually see what was happening during each action.
With Playwright you can test your app on any browser as well as emulate a real device such as a mobile phone or tablet. Simply configure the devices you would like to emulate and Playwright will simulate the browser behavior such as "userAgent", "screenSize", "viewport" and if it "hasTouch" enabled. You can also emulate the "geolocation", "locale" and "timezone" for all tests or for a specific test as well as set the "permissions" to show notifications or change the "colorScheme".
Refer: Emulation | Playwright
To make environment variables easier to manage, consider something like .env files.
Playwright scripts run in your Playwright environment. Your page scripts run in the browser page environment. Those environments don't intersect, they are running in different virtual machines in different processes and even potentially on different computers.
The page.evaluate() API can run a JavaScript function in the context of the web page and bring results back to the Playwright environment. Browser globals like window and document can be used in evaluate.
const href = await page.evaluate(() => document.location.href);This extension integrates Playwright into your VS Code workflow. Here is what it can do:
.jpg)
