Running Playwright Tests in VS Code

#playwright #e2e #testing #vscode

Hey everyone, In this post we will take a look at how to run our tests in headless mode with no browser and headed mode, with a browser. We will also explore the traces of our tests to see a step by step recording of the test execution by using the show trace option. Are you ready!

Now that we understand what our test does, let's run it by clicking the green triangle next to the test name.

As you can see the test passes. However, we didn't visually see anything. The tests are running in headless mode meaning no browser window is visible which is exactly how your test runs on continuous integration when running on each commit and pull request.

However, we can also run our tests in headed mode, meaning with a browser window visible, so we can see what our test is doing. To do this we select the show browser checkbox which is normally checked by default when you install Playwright.

Now if we run our test a browser window will pop up and we can visually see our tests in action.

With the VS code extension tests run against the chromium browser by default. If you want to run your tests on another browser, you can click on the ‘select configuration’ dropdown next to the run tests button.

You can either directly click on a browser or click on the select default profile to change your default options and run your tests on the browser of your choice or on all browsers.

However, as you can see Playwright tests run very fast, it’s basically like a fast user and that makes it hard to follow along and watch the test to ensure it is doing what you require.

That's where show trace viewer comes in. By selecting this option and running our test it will open a browser window with a full trace of your test.

From here you can hover over every action and see the Dom snapshot of what was happening during each moment. You can basically travel forward and back in time through your test. When you click on an action you can then see what was happening during that action as well as what happened before and after the event. The DOM snapshot is not a static image but a snapshot of the actual DOM. That means you can pop it out into another window and open the Chrome Dev tools and inspect the CSS or network requests etc.

Speaking of network, the trace viewer also gives us a detailed tab of all our network requests as well as console messages source code, the test log, and attachments which is used for a screen shot testing.

At the top is an image snapshot which you can hover back and forward and shows each action in different colours. And finally, we have pick locator which is very helpful for picking an element on the page. We can use this directly on the Dom snapshot by hovering over any of the elements on the page and you will see the locator highlighted underneath. Simply click the element you want to locate and it will appear in the pick locator box where you can then click the copy button to copy it into your code. This is great for debugging and helps ensure you have the correct locator in your test.

Now that we know how to run our tests, In the next post let’s look at how to write tests using tools such as pick locator and Codegen, which generates your test code as you interact with your app.