00:00 So I've got this failed test, but to debug it I would love to see visually what's happening to my app as this test runs. To do that I will use a feature in Playwright called UI Mode. To run my tests in UI mode, I will use the same command npm run test end to end and provide it the UI flag. Running this test with the UI flag does not immediately run the tests, but instead you can see it brings forth this special DevTool window. This is the UI mode.

00:30 Let's explore it in more detail. This window is split in numerous sections. So let's start from the left. I can see the list of all my tests over here, some controls, how to run them. I can search for tests by name or tags.

00:42 I can refresh them in case I've added a new test and it's not appearing here. Here I can also have a server side logs which is really handy if I'm testing apps that have server side. So at least now I can see, okay, my application started correctly. There are no errors. This is already some great pieces of information when I'm debugging.

00:58 Now I will run my failed test by hovering over it and clicking on this play button. Immediately you can see things happening on the screen. Here on the left, there is a list of actions that the test performs. Up top, there is this chart that allows me to travel in time, basically approaching and viewing my end to end test as if I'm editing a video. This is my timeline, which is really cool.

01:20 On the right, I can see the browser representation, which gives me the look in the app live as the test goes through it. And below there are a couple panels that help me figure out what's happening, like errors that I see over here, what gets printed to console, the network request, and so forth. So now I know that my test failed. If I scroll down, I can see this is the fail assertion over here. If I double click on it, I will focus on this action.

01:45 You can see this timeline focusing here, and I can explore what happened before this action and after. So before, I was on a different page, then I clicked on the notes, and I arrived at this screen. So at least I can confirm that the page navigation was correct, but something is still failing. And to figure out what, I will take a look at the failed assertion. So I know that it fails because this element assertion times out.

02:09 But I can see this heading element on the page is right over here. So why is it erroring? I can double check myself and check the locator of this element if I click on this pick locator button. And now I can hover over elements on the page and by clicking on them, Playwright will print me this copy pasteable way to describe a locator for this element. So I don't wanna select the link here.

02:32 I wanna select the heading that's a child of this link. I can see here in the area snapshot, then clink has this heading element with this accessible name. In this case, it's the text content of the element. But here's the thing. I can clearly see that it uses user's full name and not the username as the accessible text.

02:51 And I think this is where I made a mistake. I constructed this locator incorrectly. Now instead of going back to my code and trying to find this failed assertion and this test, I can go there straight from the UI mode. If I go to the source, I can see that Playwright already selected this failed assertion. I can click on this open button, and I will immediately be brought back to my IDE focused exactly at the failed assertion.

03:16 So So let's fix it. I know that instead of user dot username, I should use name instead. I will save this action, and I can run the test again, or even run it in watch mode perhaps, if we wanna do any more adjustments. So let's run it. Now the test goes through and finally passes.

03:35 I can confirm that this last step actually found this element over here, you can see, and proceeded with asserting the list of notes and the particular notes content. The UI mode is really powerful, and Polaroid gives me a lot of tools here to figure out what's wrong with my tasks. And even more, when I wanna dive deeper and just open this exact browser window, I can go here in this overview and click on this open icon, and this will open the actual Chrome window that I can use to debug in whichever way I'm used to. Basically, I have all my dev tools here. The only thing to keep in mind is that the state of this app is frozen in time.

04:09 It's no longer interactive. It is a snapshot. But it can still be useful because I can access a lot of elements. I can have that whole dome here under my fingertips, see the console, dive into sources, explore the network, and so forth, maybe even use my Chrome extensions to help me figure out what's wrong with my app. What I love about the UI mode is that I don't have to write my tests in any special way or have some configs for it to work.

04:33 Just passing the UI flag is enough for Playwright to bring forth this UI mode and for me to take advantage of it while developing and debugging. What I actually like to do in my practice is just spawn the UI mode and keep it there in the background as I'm working on my app and as I'm writing my end to end tests. It gives me an immediate visual summary over my test suite and helps me debug failed tests when they happen. As you might have noticed, using the UI mode is equivalent to running your tests in the Hetful browser, the one you can see. So while that's handy while working on your tests locally, unfortunately that's not something you can use on the CI.

05:07 That's what I would have said if Playwright didn't have a way of running any test in UI mode, even those tests that happened in the past.