Postmortem Debugging Failed Tests with the Playwright Trace Viewer

Instructor: [0:00] Here, we have the sample test that adds a to-do, and then makes a very simple typo in what has failed, versus what is expected. Essentially, designed to fail so that we can demo some postmortem debugging.

[0:11] Within the default playwright.config.ts file, you can see that there is an option for traits, which is currently set to on first retry. Retries are not something that are going to happen locally, as you can see in the retries' option.

[0:24] It is currently configured to do two retries on CI servers, but on localhost, it's only going to zero retries. These are good default options because on localhost, you normally don't want the test to retry again and again, you want it to fail fast. If you need to retry, you can retry yourself.

[0:41] Additionally, we have better tools than the Trace Viewer for debugging tests locally. For example, we can use the Playwright Inspector, or we can even run the test with the VS Code debugger attached as we have shown in previous lessons.

[0:53] However, the Trace Viewer is great for debugging tests that have failed on the CI server, and you want to debug what happened after the fact.

[1:01] Now, here we have the test failing on CI. As we have demoed before, within the summary for this particular test, we have the artifacts that are uploaded to GitHub. These artifacts will also contain the trays for our failed retry attempt.

[1:14] The simplest way to view the trace file is to simply extract this particular report into the root of our Code project. Here we have that zip file extracted within the project root. The great thing about doing that, is that we can run the standard command that we have seen before, which is npx playwright show-report to look into this particular report.

[1:34] Of course, we have that single test that is failing. If we click through it, it's not particularly hard to see why this is failing. It is telling us that the text that it received is different from the text that was expected.

[1:45] For more complicated scenarios, it's great to have a visual reference of what the test was doing, and what the UI was looking like. That is what is provided by the Trace Viewer.

[1:54] As we saw in our playwright.config.ts file, the trace is configured to be collected on first retry. Sure enough, the trace is present in the first retry, and we can simply click it to open up the Trace Viewer.

[2:08] There are a number of portions to the Trace Viewer UI. Let's go through them one by one.

[2:13] At the top, we can find the timeline. You can scrub the timeline to see screenshots of the UI at various points in time. Also, present in the timeline are various bars that demonstrate the actions that Playwright is currently doing. You can click on these bars to select the action within the Actions Panel as well.

[2:31] Then, of course, there's Actions Panel, and you can click on any action to view the action log. Within the center of the action log, there are three snapshots of the DOM. The action snapshot might highlight which element Playwright is about to interact with.

[2:45] The first snapshot contains the state of the DOM before that action takes place. The after snapshot of the DOM is what the DOM looks like after Playwright has carried out the action.

[2:56] We are using the term DOM snapshot because this is not a screenshot. This is what the actual DOM looks like, which means that we can do some simple interactions, and even inspect elements to help us debug any issues using the browser developer tools.

[3:11] Finally, on the far-right side of the UI, we find additional panels to help us debug any issues with our actions. Whenever we select an action, we can see some call details. We can see what was printed to the browser console within that action. We can see any network requests that were made as a part of this action.

[3:28] Within the source panel, we can see from where in our source code, this particular action was triggered from. As you can see, the Trace Viewer is a great way to debug any issues with a test after they have completed their execution.