Fast and easy authentication with Playwright

profile
Tim Deschryver
timdeschryver.dev

I've already said that Playwright offers a smooth experience to write end-to-end tests. In this post, we're taking a look at how we can authenticate a test user and reuse its authentication state.

Note

Hi there! 👋 If you're using Playwright v1.31+, you can take a look at a better implementation of this technique in my Revamped: Authentication with Playwright post.

With Playwright, the authentication process can become a part of the test flow because a Playwright runs on different domains during a single test case. It doesn't feel abnormal because the authentication code looks the same as the rest of the test. Yet, including the authentication process within the test flow has a major drawback.

The caveat is that the test suite exponentially slows down when more test cases are added. For every test case that's added, you would need to authenticate the user over and over again.

Of course, Playwright provides a solution for this issue, otherwise, I wouldn't be so exciting about Playwright and I wouldn't be writing this blog post. With the global setup and teardown functionality it's possible to set up your test environment and to tear it down afterward. We're particularly interested in the global setup, which we use to authenticate a test user and reuse the authentication state in every test case. In other words, we only want to go through the authentication process once.

Authenticate the user link

To step through the authentication flow before the test suite is run, create a new file in which a default function is exported. In the next step, we're going to configure Playwright to invoke this method, but let's first focus on the content of this method.

You can choose where to add and name this file but I like to have it close to my end-to-end tests, that's why I add mine directly in the end-to-end test directory.

The idea behind this setup file is that we can authenticate a user once, keep the authentication state aside (persist), and reuse (rehydrate) this state when the test cases are executed.

Inside of the setup method, we:

  1. pluck the environment options from the config to make the authentication flow environment-specific;
  2. instantiate a new browser page by using the Playwright API;
  3. navigate to the login page;
  4. fill in the user's credentials;
  5. sign the user in;
  6. persist the state at the storage state location (more about this in the next step);
  7. close the browser;

I've also included some logs just to see where we're at during the process.

To further enhance this basic setup, I also like to:

Configure Playwright link

To enable the global setup, add the globalSetup option to the Playwright configuration. The value of this option is the file location of the global setup file that we've just created in the previous step.

To load the persisted state when the test cases are run, you also need to set the storageState option, which points to the persisted authentication state that's created in the previous step. This storage file includes a dump of the local storage and the cookies of the page. Don't forget to exclude the storage file from git by adding it to your .gitignore configuration.

Usage with code generation link

In Writing your first Playwright test we've seen how we can leverage the Playwright code generation command to write the test cases for us while we simply interact with the application.

To use the persisted storage state while using the codegen command, refer to the persisted storage file by using the --load-storage flag.

Conlusion link

Yet again, Playwright provides a useful method to a common task. We could write this logic ourselves or use a plugin for it, but it's nice to know that the Playwright team thinks about us and have this feature built into Playwright.

When we extract the authentication flow from the test cases into a global setup, we gain two big benefits.

The test cases don't need to worry about the authentication process and this removes extra fluff from the test cases, the test code only contains the important path.

The test suite runs a lot faster because the test user only needs to be authenticated once, and not for every test case.

Happy testing!

Incoming links

Outgoing links

Feel free to update this blog post on GitHub, thanks in advance!

Join My Newsletter (WIP)

Join my weekly newsletter to receive my latest blog posts and bits, directly in your inbox.

Support me

I appreciate it if you would support me if have you enjoyed this post and found it useful, thank you in advance.

Buy Me a Coffee at ko-fi.com PayPal logo

Share this post

Twitter LinkedIn