Debugging Playwright Tests

When things go wrong in your playwright spec, which is inevitable in all things software development, it's great to be able to debug your tests. A key advantage of the Visual Studio Code playwright extension is the built-in debugger. This allows us to pause and inspect our test code as well as the browser to identify any issues that might exist. To demonstrate the debugger, we create a very simple test. We bring in test and expect from playwright test, and then we use test or before each to request the fixtures request and page. And then as we covered in our testing API lesson,

we used request to make a put request to the API slash set all endpoint to clear any data items that might previously exist within the to-do list. Next we simply use Page to navigate to our main application. Then we create a new test to simply add a new to-do into our application. We first use the locator API to identify the input that we want to target and then type in learn playwright, followed by the enter key. Here I want to point out another neat feature of the playwright, API called page wait for response. This wait for response will essentially wait for a request

to be made to the slash add endpoint, and then for the response to complete successfully, essentially ensuring that the to-do is successfully added into the backend. Now let's demonstrate how we can debug this test. If you click on the VS code sidebar, we get the option to add a breakpoint. The red dot indicates that a breakpoint has been set. So if you were to debug this test, the code would pause at this particular breakpoint To debug the test, right click the play button and select debug test. This will start executing the test and attach the visual studio code builtin debugger to the running playwright test.

So as we can see, the test starts executing up till the point, till the breakpoint is hit. And at that particular point in time, the code is essentially stopped allowing us to essentially debug the current state of the browser. We can use the browser built-in developer tools at this point to inspect various things to essentially determine the next step for our particular test. Additionally, because the test is paused, we could inspect various things about our test. For example, by using the variables watch and the call stack portions of the Visual Studio code debugger. Once we are happy with the debugging session,

we can press continue in the debug toolbar to essentially let the code run to completion. A key feature of debugging with the VS code extension is the ability to inspect playwright locators to figure out exactly what Tom element it is selecting. We can use this to fine tune our locators to do exactly what we want. As an example, let's use a simple locator to find all the input elements that exist within the dome. Now if you debug the test, again, of course it'll execute till it hits our breakpoint, at which point it'll be pause. And now we can move our cursor to any

of the locator parameters to see exactly what playwright would locate. So for an input playwright actually locates three things, and this is definitely not something that we want. So we inspect the dome, select the element that we actually want to select, and here you can see a good option would be to find some Label that exists within the to-do list class. And we can actually play around with the locators while continuing our debug session. So we replace a simple input selector with a to-do list, CSS class selector, followed by a nested label. And here on the left you can see playwright is highlighting exactly what it'll select.

Our locator is selecting the learn playwright label, and this is exactly what we want. With that identified, we can now stop our debug session and continue fine tuning our code. So we store this locator into an items variable, and then we expect that the items should have the text consisting of a single array item, which is learn playwright. So now let's just debug this test again to see what it is doing. It'll run till, of course, it hits the break point, and at this particular point we can inspect the browser and everything seems to be in order. So we just let it continue.

And of course, this particular test will pass the extension automatically picks up the first playwright project as the default debug profile. And just like we can modify the default profile for running tests, we can modify the default profile for debugging tests. In the testing panel within Visual Studio Code, use the dropdown next to the debug button. And here you can select a default profile. You can see that right now it is defaulting to chromium, but let's change that to something else like Firefox. Now whenever we debug any test, it'll be debugging using Firefox. An additional thing that I want to point out is

that you can also debug a test from within the test explorer. Clicking this button would essentially be the same as a right-Clicking in the sidebar and selecting debug test. Since we've changed our default debug profile to Firefox, this time when the test executes, you can see that it is running within Firefox. Of course, our application and our test are fairly resilient, so if you let them run to completion, you can see that the test passes.