Creating a Playwright Project

Once you have the basic developer tools downloaded, playwright comes with an ICLA command to build you a basic project so that you can immediately start playing around with tests within an empty folder. We can initialize a new playwright project from scratch by executing the command NPM in it playwright at latest. It'll ask you for a number of options that we can configure, and for most of them, we will select the default. So we will select the default of TypeScript. We will select the default of putting the tests into the test folder. However, for GitHub actions, we will select yes as we will be covering how

to use playwright within GitHub actions. So press y to continue with GitHub actions is true. And for the last option as well, we will select the default, so just press enter because we want playwright to install the process for us so we don't have to do that manually. And congratulations, you've created your first playwright project. Feel free to explore more of the terminal output that has been presented to you, and once you are happy, open it up within Visual Studio Code. Using the default project template is a great way to learn about the current best practices when working with playwright.

Let's do a detailed walkthrough of the files that have been created for us so that we can lift and shift the same infrastructure to any project that you might already have. The simplest and perhaps the most significant feature of this particular template is the fact that within package do Jason, we now have a dependency to playwright slash test. This is the only package that you really need in order to start using playwright in your own projects. Next, we have the file playwright config ts, which no surprise is used to configure playwright. Here you can see the test DIR is pointing

to the test folder, which is one of the options that we selected the default for when creating this project. There are lots of configuration options in this file and many of these will get covered in this course. But a critical one that we want to point out right now is the projects option, which is used to configure which browsers or tests are going to run against. Right now we have three projects configured by default, so our tests will run against chromium for Chrome, Firefox or Firefox and Web Kit for Safari. Also present within the template is the test folder, which only contains a single test file to begin with.

There are only two tests present within this file, and we will look at the API details of test page and expect and lots of other things throughout this course. The final file worth pointing out within this template is the dot GitHub folder, which contains the workflows folder, which contains playwright yaml. This file is used by GitHub actions to execute our tests on GitHub so that we can all see the final result of how our tests are functioning when multiple people are working on the project. The playwright package comes with an ICLI tool that we can use to run playwright tests on the command line.

So let's open up the terminal in our project folder and execute the command NPX playwright test. This will start executing the tests which are present within the test folder against all the different projects that we had Configured, which is Chromium, Firefox, and Safari. If you have done end-to-end testing before, you might be surprised by how quickly playwright manages to run its tests. Once the test complete playwright also generates an HTML report, which you can find in playwright test report, and we can open it up right now using the command that playwright is pointing out,

which is NPX PLAYWRIGHT Show Report. This starts a web server and opens up the report within our browser. Here you can find the two tests that we had within example, spect, which is has title and get started link. Also, you can see that both of these tests executed against all the different browsers and how much time each individual browser took to execute that particular test. We can even drill into the test to see the steps that were executed inside the test and even see which line of code within our test is responsible for executing this particular step.

The ability to explore our test results in a nice user interface makes it very easy to maintain our playwright tests. As more and more tests get added and more and more people join the project. Once we are done exploring our test results, we can jump back to the terminal and exit the show report Functionality by pressing Control C playwright also comes with support for GitHub actions, and this allows you to have nice, clear continuous integration among all your team members, allowing you to collaborate safely without breaking tests. This functionality is driven by the playwright Yammer file present within the GitHub

folder to see this file in action. Let's commit all the code to source control by using the source control panel within Visual Studio Code initializing a new repository. Next, we stage all of the files that we have, essentially adding them to source control, and then add a nice commit message like in it, and then press the commit button to commit these changes to Git. At this point, we have all of the source files that we have seen initialized and stored within a local GIT registry. The next step is to publish this to GitHub. To do that, we press the publish branch,

and then you can select a public or a private repository. And for the purposes of this demo, we will publish to a public GitHub repository. Once the upload is complete, you will get the option to open it up on GitHub, and if you click that, we are taken over to github.com where we can see our source code uploaded and shared with everyone. Next to our commit, you can see this nice yellow dot, which actually points to the fact that GitHub actions have already started. We can look at the details for this action, and here you can see it is running through the steps that were present within the playwright YAMA file

that we previously looked at, and right now it's actually executing the command and PX playwright test, which is the command that we ran previously, locally, to run the tests ourselves. Now, hopefully all of these tests will pass, and eventually we will get a green take for this particular commit. If you go into the summary section for this particular action flow, you can find within the artifacts at the bottom of the summary page playwright report. This contains the same HTML report that we previously looked at, so if we download it, extract the zip file, and then look at its index html, you can see that it's similar to the test results

that we previously saw locally when running NPX PLAYWRIGHT Show Report.