If you already have a subscription, you can sign in.
Enjoy free content straight from your inbox 💌
00:00
While screenshots and videos on failures are great first steps for debugging, they don't provide much context about the internal brain state of the playwright test or the state of the web application. So this is where the awesome playwright Trace Viewer comes in, demonstrate the Trace Viewer. We have a very simple test that is designed to fail and of course the reason why it fails is because we add something cheese with a Z, but we expect it to be cheese with an S. Now let's run this test through playwright by using NPX playwright test followed by the test name, which is Fail Spec ts. Now one thing that I wanna point out is
00:33
that traces within playwright are disabled by default. Just like videos are disabled by default because recording a trace does consume some system resources, but we can provide a custom value for this option on the command line by using minus minus trace and here we are setting the trace to be on. Now of course, once this test completes, it will fail and because it fails, playwright will automatically open up the show report command for us. Within the details of the fail test, we now have the section called Traces, and if we click that, we get access to the playwright built in Trace Viewer.
01:06
Honestly, this is a pretty powerful way to debug a test that has already been executed. You can toggle between a light and dark theme from the top right hand corner and I'll just toggle to light for the purposes of this demo. A very nice feature of the Trace P UI is this screenshot section, which actually shows you what the application looked like as the various actions were carried out. Below that we have the action section, which contains the log of the various actions that Bear had carried out along with the times, and we can hover over the different actions to see what the UR looked like when that action was taking place. In a tab next to the actions is the metadata which contains
01:42
additional information about the test. Let's go back to the action tab and discuss the heart of the Trace viewer, which is the dorm snapshots portion. Whenever we have an action selected, for example, right now we have located type selected, the action tab of the snapshot is going to highlight which dorm element the action is going to interact with. You can see right now that the type keystrokes are going to go to the new to-do input within the dorm snapshots. We also have the before and the after tab, and you can see that before the action was carried out, the input was empty, and
02:13
after the action was carried out, the input contains the text by cheese. Let's go to the next action, which is located at press, and to find out what particular key was pressed. We can look at the call section in the bottom panel amongst other things. If you scroll down, you can see that the parameter that was passed for the key for located or press is the enter key. There are other tabs within the bottom panel as well. If there were any console or log statements, they would show up within the console tab. If there are any network calls, they show up within the network and you can see that we did make a call based on this action
02:46
to API slash ad, and if you scroll down, we can even see the request body and the response body. Additionally, the bottom panel contains the source tab, which highlights from where within our test code This particular action was carried out. Within the actions panel, you can see the action that failed highlighted in red. If you select it, you can see the reason why it failed. It expected to receive cheese with an S, but it got cheese with a Z. And perhaps one of the hidden most powerful feature of the playwright trace view is the fact that the dorm snapshot is actual dome.
03:20
So you can actually inspect this, and right now you can see that the heading within the user interface is not just an image, it is an actual dome H one. You might have realized that when running our test locally, we can do a lot without using the Trace Viewer as we can just debug our tests with our IDE as we've done in our previous lessons. But where the Trace Viewer is really useful is when tests fail. On our CIO continuous integration server, as you mentioned, the default for the trace is off, but from within our playwright or config ts, we can provide a different default value.
03:53
For example, the we are setting that value to be on first retry, and in case you are curious, the possible values for trace are the same as the possible values for video, and they have the same impact. Now with the value on first retry, the trace will only be recorded if the test failed and a retry is happening. And as we saw in a previous lesson, retries are controlled with the retries option. And when our tests are going to be executing on the CI server, we have a default value of two, so the test will be retried twice. Now I've just pushed this test over to GitHub and you can see that it has already started executing.
04:27
If you look at the details, the test will eventually fail, and within the summary tab, we will find the artifacts just like we previously covered in our screenshots and videos. Listen, I'm going to extract this zip file into a folder called Playwright Report on my desktop. Now, in order to view trace this properly, we actually have to open them up using a proper web server, and fortunately, a proper web server already comes bundled. Whenever we install playwright, we execute the command that we've seen previously called NPX playwright short quote, and simply provide the path
04:59
to the playwright report folder that we just extracted, which lives on our desktop. This will launch the playwright report viewer, which we have seen before we jump into the test that failed going to the first retry because that is when the traces will start to get recorded. Scroll down till we find the traces section, click on the trace, and here we have the full Trace view UI ready for us to start exploring what went wrong with this particular test. Here are the steps that I follow when debugging remote failures. First, I look at the screenshot, then I look at the video, and if I still don't know what has happened,
05:33
then I break open the trace viewer. As always, thank you for joining me and I will see you in the next one.