Playwright is a framework for reliable end-to-end testing of modern web apps.

playwright

In this course we demonstrate how to get started with Microsoft Playwright. We follow this up with various features of Playwright that make it extremely easy for you to test and automate modern web applications. 

Artem Gromov

This lesson covers the basics of Playwright's testing API such as the page object, locator, locator methods and expect.

Playwright Tests API Basics

In this lesson we demo how you can quickly get setup and start using Microsoft Playwright for cross browser Web Application testing.

Setting up Microsoft Playwright

In this lesson we look at how you can add playwright to your existing web application. Along the way we also look at other neat stuff like beforeEach, describe, async web-first matchers and the hasText locator option.

Adding Playwright to your Web App

We look at the various features of the VSCode Extension for Playwright and how it can help you with your testing workflow.

vscode

Playwright VSCode Extension

In this lesson we look at how you can do simple VRT (visual regression testing) using Playwright tests.

Visual Regression Testing with Playwright

In this lesson we look at why you would need to generate snapshots on your CI server. We follow this up by creating a simple Github Action that will generate new snapshots against a pull request once you leave a specially formatted "slash command" style comment.

Generate Playwright Snapshots on your CI Server

In this lesson we look at how you can use the playwright inspector to debug any issues in your tests. We run through a sample test and guide you through the various portions of the playwright inspector UI.

Debugging Playwright Tests with Inspector

In this lesson we introduce the codegen feature of Playwright which can be used to quickly generate automation / test code.

Quickly Generate Playwright Tests with Codegen

Playwright provides a powerful tool in the form of the trace viewer to help you debug any issues in your test after they have failed. That is exactly what we demo in this lesson.

Postmortem Debugging Failed Tests with the Playwright Trace Viewer

A common post mortem debugging tool for e2e tests is screenshots and videos. These can be enabled via options in the Playwright config and that is what we demo in this lesson.

Capture Failed Test Videos and Screenshots with Playwright

In this lesson we look at various ways you can select different elements on page using Playwright Selectors. We also demo playwright selector engines and selector chaining

Playwright Selectors

In this lesson we demonstrate how you can create Page Objects in Playwright. The Page Object Model (lovingly called pom) is a great way to simplify your test code and make it more easy to understand and maintain in the long run.

Page Object Model Pattern with Playwright

In this lesson we look at the Playwright Test concept of Fixtures. We demo the creation of various fixtures and explain the idea behind browser, context and page.

Playwright Test Fixtures, Browser Context and Page

Playwright provides a simple library that you can install via npm for automating various browser engines. That is what we demo in this lesson.

Playwright Library for Browser Automation

egghead

Use Playwright to Test and Automate Web Applications

https://app.egghead.io/api/v1/lessons/playwright-playwright-tests-api-basics/subtitles

Instructor: [0:00] To demo the fundamentals of Playwright test API, we create a new file called basics.spec.ts. The two key imports that you will need in order to create a Playwright test are test and expect.

[0:12] We get them from the playwright/test package. Now, one good thing that I want to point out about Playwright is that unlike Mocha or Jasmine on Jest, Playwright does not work with globals.

[0:21] This means that these imports will not fight with global testing packages that you might have and can be used perfectly fine with Jasmine, Jest, and Mocha.

[0:30] To create a basic test, we use the test function, provide a nice string for the test name, which we are calling math works, and then provide an async function, which will be executed when we want this test to run.

[0:42] We can use the expect method to assert any behavior within our code. For example, we can assert the fact that one plus one should be equal to two.

[0:51] To run the test, we do the same thing that we did before which is open up the terminal and execute NPX Playwright test, but this time since we only want basic start spec.ts to execute, we can pass the path to this file. Additionally, instead of running it across all the browsers, we can specify that we only want to run it with Chromium by using --project = Chromium.

[1:13] Finally, instead of the test results going into Playwright report, we just want to see them log to the console, so we can use --reporter is equal to list. When we run this command, no surprises, it works exactly as you would expect.

[1:28] Like other testing frameworks, Playwright also allows you to use .only to run one test. For example, here we are creating a test called page demo and we only want this test to run for now. Therefore, we use test.only.

[1:42] Playwright tests get access to a page object that has passed to the test function. We can use this page object to interact with the particular tab within a browser. For example, we can use the method page.goto, to navigate to a particular URL.

[1:57] Just so that we can see this navigation on screen, we'll add a delay of two seconds after this page.goto. We've been running Playwright in headless mode, but we can pass in an additional argument called --headed so that we can see the browser executing our test.

[2:12] You can see that we navigate to google.com, wait for two seconds and then the test completes. One key method within the page object is page.locator, which can be used to get access to elements so that we can interact with them on the page.

[2:27] For example, when you visit google.com, we have this input element where you will type in your search query. Now, a good way to select this particular input right now that I can see, is using input such that the title is equal to search. We jump back to our code and use page.locator, passing in a simple CSS selector for this particular input element.

[2:48] We are selecting input such that the title attribute is equal to search. Then we can interact with this element. For example, we can use the type method on the locator to send it some text. To send special characters to a locator, we use the method called press, which takes special character sequence.

[3:06] For example, we enter string in order to send it the enter keystroke. Now, if we execute this test, the browser will navigate to google.com input the text, "Hello egghead" and then perform a search by pressing the enter key. Now, one-key feature about direct locators is that they are automatically retrying.

[3:22] That is, whenever we call locator.type or locator.press, Playwright will search for that particular locator at that point in time and will keep searching till it finds it or the test times out.

[3:34] For example, if you search for an input with the title equal searches, which is not something that exists on google.com, Playwright will keep searching for certain input to show up and only then will it try to press the enter key.

[3:46] Now because this particular locator does not exist, this test will eventually time out and we can see that in the test failure. Now traditional testing frameworks might have failed with an error like, cannot press enter on undefined, whereas Playwright fails with a much better error specifically stating that it cannot find this particular selector.

[4:04] As a side note, this test fails after 30 seconds because that is the default timeout that is set within playwright.config.ts. You are free to modify this time out to whatever value you want. For most people 30 seconds would be fine because Playwright tests are pretty done fast.

[4:21] Now, one final thing that we want to mention is that, when you are using the same locator again and again, feel free to move it into a local variable. For example, we can move this locator for the search input into a local variable called search input. Then use the same locator for the type as well as the press methods.

[4:37] Now, at runtime, whenever this type and this press are going to execute, that is the point in time at which Playwright will try to use the locator to find the particular element.

https://app.egghead.io/api/v1/lessons/playwright-playwright-tests-api-basics/transcript

https://app.egghead.io/api/v1/lessons/playwright-setting-up-microsoft-playwright/subtitles

Instructor: [0:00] Getting started with Microsoft Playwright is pretty easy. We can open up the terminal and run NPM in it Playwright and provide a name for our application which we are calling Egg Playwright demo, and we'd be good to go.

[0:12] We get to choose a few options, whether we want to use JavaScript or TypeScript. We're going to select TypeScript. Where do we want our tests to exist? We'll use the default of the tests folder, and whether we want to add GitHub actions.

[0:24] We will go with the default of yes for this as well. Now, this will install all of the dependencies and set up a new folder with Playwright ready to go. Once the installation is complete, we can CD into this Egg Playwright demo folder and open it up within our IDE.

[0:39] The first thing that we look at within this template folder is the package.json. As you can see, the only dependency that we need is @playwright/test. Now, Playwright test is configured with this file called playwright.config.ts. Within this config file, you can see that our test directory is pointing to the test folder, which is something that we selected when we created the template.

[1:01] Now, in my mind, there are two key value propositions of playwright. First is its JavaScript first approach. You don't need to install something like Java, which is required for selenium.

[1:11] Second is its support for cross-browser testing. Our playwright.config.ts contains the section called projects, which specifies the process that we will be testing.

[1:21] Our tests will run under Chromium, Firefox, and WebKit, which is Safari. Now, the tests that we will be running are all contained within this file called example.spec.ts.

[1:31] The contents of this file are not particularly important for this getting set up, and we will look at APIs of different things. For example, page, locators, actions such as fill and press, and expectations in future lessons.

[1:44] Now, one more thing that got set up for us by Playwright in it is our GitHub action. We can find this in the .github/workflows/playwright.yml file.

[1:53] This file is pretty simple. Fundamentally, it will run some jobs on the main and the master branch, and the key job that it will run is this command npx playwright test.

[2:03] This is exactly the command that we can run locally to run playwright tests ourself. We open up the terminal and execute npx playwright test.

[2:12] As you can see, since we have three different browsers that we are testing, Playwright automatically splits it into three separate workers. Now, once the test run completes, it generates the results into this folder called playwright report.

[2:25] We can open this up within our browser ourselves or we can execute this command npx playwright show report for playwright to open this up for us.

[2:34] Within the report, we can see the same test for different browsers, and we can dive into the individual tests by clicking on them. Within the test, we can see the commands that were executed by Playwright. We can click on the individual commands to see where they originated from within our code. For example, this particular locator.press originated from line 17 of our example spec file.

[2:57] Now, as mentioned, these are exactly the tests that will run by GitHub actions if you push our code to GitHub. We can dive into an individual test run by clicking the GitHub status icon next to any commit.

[3:10] This particular test completed successfully and we can find the results within the summary tab in the attached artifacts for this particular test run.

https://app.egghead.io/api/v1/lessons/playwright-setting-up-microsoft-playwright/transcript

https://app.egghead.io/api/v1/lessons/playwright-visual-regression-testing-with-playwright/subtitles

Instructor: [0:00] Common requirement in web application testing is to make sure that your web application looks visually exactly as you expect.

[0:06] For example, we want to make sure that this button is this color of blue with this text of white and this row is in there. We can do that quite easily with Playwright as it supports visual comparisons.

[0:17] Within an example spec file, we bring in the usual suspects, which are test and expect and create a before each to just navigate to the localhost:3000.

[0:26] We create a new test, and within this test, we will be doing the visual regression testing for this particular button.

[0:32] Doing the test is quite easy as we can get a screen shot of the page by using awaitpage.screenshot.

[0:38] Then, we can expect it to match a given screenshot that we have saved in the past under a given snapshot name, which we are calling buttonbase.png.

[0:48] Now, of course, when we start off, this particular image will not exist and the test will fail. However, when it fails because of a lack of an image, it actually creates that image for us. You can see that in the error details.

[1:02] Now this image is created in a folder right next to where our spec file is. We can see that within the file explorer. This is a PNG file, and this is what it looks like. With this image file in place, the next time that we run the test, it will pass because of course, the screenshot will match what already exists.

[1:22] Now, if you were to modify the page for example, remove the rows from the button component and then run the test again, this time we will expect the test to fail because the new image does not match what we have saved previously.

[1:37] For these cases, it will also generate unexpected actual and a diff file and we can open them up externally, or if you just scroll down, you can see them in line with the test results. This is the screenshot that we received in this test run.

[1:52] This is the screenshot that already existed, and this is the difference. The grayed-out portion of the diff image is what matched and what had a difference has been highlighted in red. In our case, the rows is missing and the button has shrunk a bit.

[2:07] Now, you could move the actual file to be the snapshot, but there's an easy way to do that by simply adding --updatesnapshots to NPX Playwright test. With this command, the tests will pass and the snapshots will be updated. You can see the updated image in the snapshots folder right next to the spec file.

[2:28] A common issue with doing visual regression testing, is that it can be a bit too aggressive. Fortunately, you can soften that up by providing a custom threshold. You can either provide it to your individual tomatchsnapshot calls as an extra options object, or alternatively, you can do it globally within your playwright.config.ts file.

[2:49] Within the expect section, you can provide a default for tomatchsnapshot. The threshold value is actually just passed in to the underlying Library called pixelmatch.

[2:59] It takes values from zero being extremely strict to one being completely lenient, and the default is at .1.

https://app.egghead.io/api/v1/lessons/playwright-visual-regression-testing-with-playwright/transcript

https://app.egghead.io/api/v1/lessons/playwright-debugging-playwright-tests-with-inspector/subtitles

Instructor: [0:00] We will be using this simple reference test, which adds a few to-do items in a simple to-do app to demo what is known as the Playwright Inspector.

[0:08] To start the Playwright Inspector, you run the command that you are already familiar with, which is npx playwright test, but you add a command line flag called --debug.

[0:17] This will start your test in headed mode, start, what is known as the Playwright Inspector, and pause it at the first action that is present within your test.

[0:26] For our case, this particular action is page.goto for the to-do mvc app. The Playwright Inspector provides you with a button that allows you to step through the various actions that are present within your test.

[0:37] As we carry out the video sections, you can see them being locked out within the actions log. For example, right now, you can see that we have carried out page.goto, locator.fill, locator.press, and currently we are paused on expect to have text.

[0:53] In the middle of the screen, you can find the Playwright Selector explorer. Its text continues to update as the different actions interact with different selectors, but you can click the Explore button to discover what Playwright thinks might be good selectors for various items on screen.

[1:07] For example, to select the active button within the footer, Playwright thinks that a good selector is text=active.

[1:14] Additionally, the test is running in a headed browser, which means that you can use the browser tools to debug your web application in case of any issues.

[1:22] For example, we can inspect this particular label on screen right now, and you can see that it is a label within the DOM.

[1:28] Finally, when you are done with your debugging of the test, you can continue by pressing the Resume button and it will run to completion.

[1:37] As you would expect in our particular case, this test passed.

https://app.egghead.io/api/v1/lessons/playwright-debugging-playwright-tests-with-inspector/transcript

https://app.egghead.io/api/v1/lessons/egghead-quickly-generate-playwright-tests-with-codegen/subtitles

Instructor: [0:00] Playwright also ships with a code generator that can generate the tests for you. To get started, run npx playwright codegen. Then, we provide an output path for our file name. We're just going to write it to demo.spec.ts under the tests folder.

[0:16] Now, you get to see the code that is being generated within the Playwright Inspector. The browser is running in headed mode. You interact with the browser like you normally would. For example, navigate to a particular URL.

[0:28] For every action that you carry out, the code generator will generate some code, and you can see that within the Playwright Inspector's sources panel. Just as an example, we've gone to a particular URL within the browser, added some text to an input field, and then press the Enter key.

[0:43] Once you've carried out the actions that you need for your test, you can exit the browser, and now Playwright will commit this code to file. Now, you can continue with the normal workflow that you might have. For example, open this folder up within your IDE, go to the particular test, and now we can use the VS Code extension to debug this test further.

[1:03] Once we are happy, we click Resume, and now you would probably use your deeper knowledge about the web application that has been tested to clean up the code a bit further. For example, clean up the selectors.

[1:14] Irrespective of the code quality, npx playwright codegen is a great way for you to generate some quick code.

https://app.egghead.io/api/v1/lessons/egghead-quickly-generate-playwright-tests-with-codegen/transcript

https://app.egghead.io/api/v1/lessons/playwright-capture-failed-test-videos-and-screenshots-with-playwright/subtitles

Basarat Ali Syed: [0:00] In addition to the Trace Viewer which we saw in a previous lesson, another postmortem debugging tool that is provided by Playwright is that of taking screenshots as well as recording test videos. To demo these features, we have the same test that is designed to fail because of a simple typo in the expectation.

[0:17] Unlike traces, screenshots and videos are not enabled by default. We can enable them within our playwright.config.ts in the use section. To enable screenshots on all failures, we're going to use the config option which is only on failure. With this option enabled, we get a screenshot of what the URL looks like, whenever a test fails.

[0:36] Unlike screenshots, which can be recorded after a test fails, a video is something that needs to be recorded throughout a test run. One option to enable video recordings is to only enable them on a first retry, and this is a good option to have on your CI server.

[0:50] However, for the sake of this demo, we will use another option, which is retain-on-failure, in which case, Playwright will always record a video, but only keep the final file if the test ends up failing. This does make the overall run a bit slower because the video is always recording, but we are guaranteed to get a video file for any test failure.

[1:09] We run the test like we normally would -- that is with the npx playwright test command -- and once the test run completes, we get the output screenshots in the videos in the test results folder.

[1:19] Under that folder, we have a folder for this particular test. Within that, we have the image and the video. The image represents the final state of the application while it is waiting for cheeze with a z to appear. The video is exactly what you would expect.

[1:33] We can navigate to the page, edit todo item and then wait for cheeze with a z to appear, which of course, will not. Eventually, the test will terminate.

https://app.egghead.io/api/v1/lessons/playwright-capture-failed-test-videos-and-screenshots-with-playwright/transcript

https://app.egghead.io/api/v1/lessons/playwright-playwright-selectors/subtitles

Man 1: [0:00] Playwright provides a number of ways for you to select different elements within the DOM. To demonstrate that, here we have a simple web application with two buttons. We are going to be interested in selecting the first button and there are lots of ways that you can see that we can select it.

[0:14] Some things to observe is that it has a data-test attribute. It has a CSS class and it has a button that contains the text submit. Now, let's jump into our code and create a basic Playwright test to interact with this particular button.

[0:28] At its core, we navigate to localhost:3000, and then we jump into our test, where we will be playing with a few selectors. Playwright supports all of the CSS selectors that are provided by the browser, and that's probably going to be the easiest way for you to select any given element.

[0:44] For example, in order to select the first button, you could select all buttons and then only select the one that has the primary CSS class applied to it. One thing to note is that, internally, Playwright comes with a number of selector engines and CSS just happens to be the default one.

[1:00] We can be explicit about our engine choice by providing the name of the engine followed by the equal sign, followed by a selector that is passed to the engine. For this particular example, we can also write the same thing, but this time with CSS= as a prefix for the selector.

[1:15] In addition to the CSS engine, the other engine that you will use quite commonly is the text engine. This particular example will match any element that contains the case insensitive string submit. Playwright also allows you to change different selectors using the double arrow.

[1:32] You are free to use different engines in different selectors. For example, in this particular case, the first selector is using the CSS engine and the second selector is using the text engine. This particular example, we'll find any button that contains the text submit.

[1:47] Another engine is the zero index-based Nth engine. As an example, we can also select the first button by using the button CSS selector combined with Nth=zero.

[1:58] A common trick used in modern web applications is to use a custom data-test style attribute in order to identify different elements that can be accessed from different tests.

[2:08] For these cases, Playwright provides a nice shorthand. For example, this particular selector will select anything that has data-test set to submit, which of course is our submit button. To demo these selectors in action, let's turn our test using the Playwright inspector.

[2:23] We start off at page.goto. We click the first button using button.primary selector with an explicit CSS selector with text=submit selector with the button such that it contains the text submit with the button, such that it's zeroth button.

[2:40] Finally, something that has data-test=submit.

https://app.egghead.io/api/v1/lessons/playwright-playwright-selectors/transcript

https://app.egghead.io/api/v1/lessons/playwright-playwright-test-fixtures-browser-context-and-page/subtitles

Instructor: [0:00] It is useful to be aware of the concept of fixtures when working with Playwright tests. These are the objects that you destructure from the argument that is passed to your test function. Right now, we are not destructuring anything from the past in argument.

[0:14] Therefore, Playwright is smart enough not to instantiate any of those values. For example, because we're not taking a page, a page will not be created. If you run this test as it stands right now, you can see that it is pretty darn fast, taking only a few milliseconds.

[0:30] This is great news because it means that you can use Playwright tests for testing things that are not browser-based as well, and they will run pretty fast. Looking at some of the built-in fixtures that are provided, we've already seen page a number of times.

[0:43] As fixtures go, this is probably one of the most expensive ones to create. If I run it a few times, you can see that it takes around half a second on my machine. Another fixture that you can use is the browser name.

[0:55] Of course, if you're only going to be using the browser name, it's not going to actually launch the browser for you. This is going to run pretty darn fast as well. Now, the next thing that I want to demo is the layer that actually gets you to a page.

[1:07] When we ask for a page, that essentially first creates a browser. Now, this is not particularly expensive to create, as you can see, from my protector machine, it's done in under 100 milliseconds.

[1:18] The browser will be something like Chromium, or Firefox or WebKit. The next thing that playwright will have to create is what is known as a context.

[1:25] You can think of a context as an isolated browser window. This is going to be a bit slower than creating the browser because for this, Playwright will first have to launch the browser and then create the context.

[1:36] This brings us to using the page. When we request a page, Playwright will first launch the browser, then create a context and then create a new page and you can think of a page as a tab within a particular browser window.

[1:48] Now, it might seem like a big jump in time to execute going from a context to a page, but the good news is that, as we create more and more tests, it becomes cheaper and cheaper to create new pages.

[1:59] Right now, the first page is taking around 350 milliseconds, and the second page is taking only around 130 milliseconds on my machine.

https://app.egghead.io/api/v1/lessons/playwright-playwright-test-fixtures-browser-context-and-page/transcript

https://app.egghead.io/api/v1/lessons/playwright-playwright-library-for-browser-automation/subtitles

[0:00] In addition, to providing a great testing Library. Playwright also provides a core npm package that you can use for simple browser automation to demo that we have a basic node js script, where we have, an async function mean, which we invoke immediately. And we will be writing code, within this main function, we can get the playwright core Library by running npm install. Playwright, this not only installs, the playwright library, but also brings in the binaries for the different browsers for your operating system. Once you select Listen is complete. Let's jump into our code and demo some of its features you bring in the library with the simple import statement player. It comes with a few browser engines that you can launch. These are chromium web kit and Firefox. And here we are launching just a Chromium browser. We are running it in headed mode by setting headless faults because we want to see the browser window because right now, we just Deming some of his features. Once you are done with your automation code. You can remove this option and it will run and headless by default. Now will mention this tree before. open looking at the rightist, Ripley, right works on top of a browser, which is a brows, the engine followed by a context, which you can think of, as a browser session followed by a page, which you can think of, as a tab within a particular browser window, when you're working with beta test, you can get direct access to a page, but when you're working with the core API at low level, you have to manage all of these things yourself, once you get access to the page, you can use it to interact with various elements in the Dom, but right now, let's just create a pause for two seconds, so that we can see See the browser window Flash before our eyes. And finally, when you are done with your interactions. With the browser, you can exit it by using browser to close. And now, if you were to run this script, of course, you see the browser launch. Create a new context, create new page. We will see this page for two seconds. And finally, the browser will close. Now. Let's look at a few simple interactions that we can carry out by using the page object. One method that we've already seen with Pari test, is Page, dot go to, and let's just navigate to Home and at the method is Page dot screenshot, which we can use to save the screenshot of the current page to a particular file path. And we're just saving it into the screenshots folder as page dot PNG. Now, when we run the script again, it will navigate to google.com and save the screenshot to page dot PNG. And maybe open that up. You can see that we have a screenshot of the Google homepage. Now, let's debug this. Node.js script and look at some other interactions that we can carry out with the Google homepage. We set up a breakpoint right after page dot CO2. So now when we run the script, we are currently on google.com. And let's observe, this particular input that is used for searching something on Google looking at the Dom as it stands right now. One decent way that we can use to select. This input is to find something with the attribute title equals search. We will use this input to fill in some text and press the enter key. This will take us into the results page and to make sure that the results are actually displayed before. Take the screenshot. One thing that we can do is to make sure that the results stats are visible. If we inspect the element, you can see, there is pretty easy to select with the simple ID selector of results stats armed with this knowledge. Let's jump back to our node.js script and modify it to take a screenshot of a particular results page. After navigating to google.com., We use the title equals to search attribute. To find the search input, fill in the text, Microsoft way, right? Then press the enter key. And then to ensure that We are on the results page. We wait for the results stats to become visible and the existing code will, then save the screenshot to page, 2 p and g. And now, if you run this particular script, it will navigate to google.com, perform a simple search wait for the search results to show up and then save the screenshot. And we can verify that the screenshot is correct by opening up the page dot, PNG, file, that we saw before. For final closing, thoughts using the period core API for simple. Browser automation is pretty easy if you've used by writers. Just because at its core, it's the same page object with the same API across both libraries.

https://app.egghead.io/api/v1/lessons/playwright-playwright-library-for-browser-automation/transcript

Use Playwright to Test and Automate Web Applications

Basarat Ali Syed

Credits

Course Content