Amongst the various ways that exist around playwright tests. The one that I find myself most commonly using is the UI mode. It is a really powerful way of running playwright. It provides a nice solution to a common feature request, which is a running playwright in watch mode. Additionally, it has a built-in Trace viewer that you can leave running off to the side while you author your tests in a separate tool like we Code. Let's take a look To start playwright in UI mode, we execute the command and PX playwright test and pass in the command line flag minus minus ui, and this gives us the best UI experience for playwright at IT score.

We have our tests and test selection options on the left and on the right hand side we have a built-in Trace viewer. We've already looked at the Trace Viewer in our previous lesson, which is dedicated to the topic of debugging traces. So let's run through some of the options that exist on the left hand side. On the top, we find the option to toggle between light and dark mode. Next to it is a refresh button, and you can use that if the playwright UI ever gets auto sync for any edits that you might be making to the tests. In an external tool like Visual Studio Code next to it, we have the option to display the terminal output.

We will look at it again once we have run a sample test under it, we have a simple input, which we can use to filter the tests based on the text content, and we can also filter them based on their past failed or skipped status and select the projects which we have specified in our playwright config, which should be used to execute the test. If we select multiple projects, they actually show up under the test statements. So as an example, we selected all the three projects and you can see we have the option of running this particular test in any of the different projects, and as we select different project options, the UI automatically simplifies itself

to make the most sense. Let's collapse the filtering options and then talk about the meat of the left hand side, which is the tests section. At the top of the list, we have a few key controls. We have the option to start all of the tests, and as you can see, the different tests have started executing and as they progress, we can actually expand and select an individual test to see exactly what happened during the test execution. As we mentioned, the right hand side of this UI is the full blown trace viewer. It's just integrated very nicely into this playwright UI experience.

At any point, we can actually use the toolbar to stop the executing tests. From here, we can very quickly see that the test took 1 1 3 seconds. What are the different actions that executed for this particular test? What our application look like as those particular tests were executing, and then step to the different actions and debug them as much as we want. Similar to what we did in our Trace view lesson. Not only is the playwright UI a great way to execute your tests, it provides a great way of developing your tests as well. By using the watch mode, we can actually click the I icon next to any test or describe or spec file or even folders

or even all of the tests by using the top toolbar. And then playwright will automatically watch changes that you might make in external tools. And if you make any changes in something like BS code which might Impact the test result, playwright will automatically rerun the test to see if the test still passes or fails. To get a real appreciation of the kind of developer experience enabled by playwright UI mode, let's do a sample run of enabling watch mode and making simple edits to a test in a developer centric tool like Visual Studio Code. Here we've been able watch mode for a simple test,

and we can actually navigate to the IDE directly from within here using a button next to the test, which allows us to open this test within Visual Studio Code. Now because this test is being watched by playwright ui, if you make any edits over here, it'll automatically read on the test. Let's modify it so that the test should fail. We expect for the footer to be visible. While there are no active to-dos and no surprise, the footer is actually not going to show on my other monitor. Playwright has automatically started to rerun the test and it does eventually time out because it is searching for a

footer that will never show up. The great thing about the playwright UI is that the Trace Viewer is built in and we can see immediately what is the action that caused this particular test to fail. We can do other things, for example, look at the errors, which provides greater detail into why this expectation failed. Now, as I mentioned in the start of this lesson, at the top of the UI, there is also an option to look at the full output, and this is a great way to look at exactly what the playwright UI is doing behind the scenes. It is essentially a wrapper around the test execution experience and the trace collection experience consolidated into a very nice UI.