Getting started with Playwright and Playwright Test runner

Playwright logo

As you may have heard, Playwright team has just introduced Playwright Test runner in v1.12.0 version. It’s brand new test runner built from scratch by Playwright team specifically to accomplish major end-to-end testing needs such as:

• Running your Playwright test automation scripts across all significant browsers;
• Running tests in parallel;
• Having pretty handy context isolation out of the box;
• Saving your time by using fixtures;
• Screenshot, video, traces, and many many other items for test failure.

So, I’ve decided to go through and share with you my brief overview of the major Playwright Test’s features.

Installation

Let’s install Playwright and Playwright Test:

npm install -D playwright @playwright/test

install dependencies

Set up

Once you’ve installed the libraries you will need to create a configuration file.

Add a configuration file

Despite, Playwright Test runner can be used without configuration file, we are going to add it as in a real world application.

Create playwright.config.ts file and paste code snippet:

In the config file we’ve specified one browser to launch. A little bit later we will update and make it more powerful for different browsers and with various additional options.

Add a test file

Create tests directory and add tests/search.test.ts file in that directory:

mkdir tests && touch tests/search.test.ts

NOTE: You can name the directory whatever you want, but then you’ll have to update testDir property in the configuration file (because tests is the default test directory).

Once we’ve created that file, we can add first test:

Let’s look closer at the test above

Step by step:

1. We’re importing test and expect functions;
2. We’re grouping our tests together with a describe block;
3. Then we’re using the test function with all executable code;
4. Here is the argument { page } that the test has access to. It’s called fixtures . Fixtures are objects that are created for each test run;
5. Adding test data;
6. Visiting the ‘IMDB’ page;
7. Filling out the search field with the defined test data;
8. Asserting the search result text content.

Run

Now let’s run it with the following command:

npx playwright test

headless run

We haven’t seen the browser because it launches in headless mode by default, to change it we have several options:

• provide the --headed argument:

npx playwright test --headed

• add the headless property with the false value in the config file:

So, now your config should be like the config above. You can run it with the previous command to verify that browser shows up.

Run in multiple browsers

To run tests in multiple browser we just have to add them in the projects array in our config file

We’ve added Safari and Firefox browsers, and removed headless property from the Chrome. Before running it, let’s add one common headless property for all browser.

run in multiple browsers headed mode

To change viewport for all browsers add viewport property inside use object, besides you can change viewport for specific browser by adding viewport property inside browsers’s use property.

For instance:

viewport: { width: 1200, height: 750 }

Run test in specific browser

You have an ability to run a test in specific browser. Let’s make some changes in our first test and run it:

To run it use the same command as we used before (npx playwright test):

skip test in safari

Additionally, we can use fixme function to skip the test, with an intention to fix it later. It’s going to be look like that: test.fixme().

As we have only one test it’s impossible to see the difference, that’s why we need to add one more test in our suite.

So, let’s add one test to check the ‘no results found’ message in our describe block and run it:

Even more, we can run specific test by its name using command line. First of all, let’s remove only in our test and then run it with the command:

npx playwright test -g "verify no results"

Repeating setup for many tests

If you have some work you need to do repeatedly for many tests, you can use beforeEach and afterEach. For example, let’s try to refactor our test with these hooks. As you can see we’re using the navigating method in both our tests. So, we can easily move it to our beforeEach hook:

One-Time Setup

Even more, in some cases, you only need to do setup once, at the beginning of the test. Playwright Test provides beforeAll and afterAll to handle this situation.

Snapshot Testing

Playwright Test includes the ability to produce and visually compare screenshots using toMatchSnapshot. It’s very useful whenever you want to make sure your UI doesn’t change unexpectedly. Playwright Test uses the pixelmatch library.

Let’s create some test for this case and run it. On first run, Playwright Test will generate baseline screenshots and only after that Playwright Test will compare them against the baselines.

Let’s create simple visual test and run it.

For example we’d like to verify sign in page on the IMDB site:

After running the test above, Playwright Test will create few directories and files.

If you want to update your baseline screenshots you will have to use the command:

npx playwright test --update-snapshots

Test retry

One more great feature that Playwright Test provides. All in all, Playwright Test will retry tests if they’re failed. You can specify it via command line or configuration file.

• add the --retries argument in the command line:

npx playwright test --retries=3

• or add the retries property in the configuration file:

Conclusion

Playwright Test is super powerful test runner, which provides us tons of features and abilities for automation infrastructure.

Unfortunately, I didn’t cover all features. However, I hope you’ve learned something new with this article, and you’ll at least try or even more apply these concepts to your project.

One more thing, Playwright documentation is close to being perfect and you can find great examples and tips there. So, please read it.

Thanks for reading and happy testing!

If my short overview was helpful leave a comment what you’re interested in and who see maybe it will be the plot for the next story.

Btw, highly recommend to subscribe to Test Automation Weekly digest to keep up with latest news in test automation world.