*Knock-knock*, who’s at the door?

Authentication is a process of recognizing user identity. When a user enters their credentials (usually login & password) and, depending on an identification strategy, a user is being determined by a system. Then all necessary user permissions are verified, and they might have access to particular resources (aka authorization).

But that’s not the point right now. The goal is to explain how to deal with authentication on your e2e test setup with the playwright test library.

Created by Microsoft, playwright makes the process of writing e2e scenarios easier than we’ve ever imagined. It’s cross-platform, resilient, has an amazing set of tools like trace viewer, inspector, codegen and so on. And one of the major advantages is full isolation with browser context, which is really helpful for auth itself.

Let’s start with the requirements first and answer the question, “What do we want to achieve and see as an outcome of the exercise?”

• To check if the authentication works as expected;
• To store the state of the authentication (in our case, cookies-based) and reuse it by other scenarios;
• To authenticate a user at the beginning of all e2e scenarios executed.

If we have a look at the official documentation, we’re able to see some basic information about authentication handling. But in fact, it’s a bit tougher.

First off, we want to log in via the UI and then reuse a state in multiple scenarios.

To make it work, we should use globalSetup which is, by the way, triggered once before all test suites. It’s just a function and a property in the playwright configuration file. So, that’s place where all our own logic will be implemented. Here is our sample configuration file (test configuration):

The next step is the implementation of the globalSetup function and the authentication logic itself. For that purpose, I’ll wrap the scenario to the AuthPage class with a single public method login.

In general, we’ve passed the configuration, launched the browser and created a new page. The most exciting here is page.context() that stores the browser context (cookies, local storage and so on) to the path we’ve provided in the configuration.

And finally, let’s check the authentication scenario quickly:

So, basically, we’re done here. The logic is implemented, connected to the test runner and runs before all other scenarios.

In the meantime, depending on your backend logic, the state of the auth might be reused several times. For instance, in our case, the access token was valid for a couple of hours, so there was no need to run end-to-end authentication logic over and over again.

Let’s try to improve it by changing the globalSetup function.

Let’s change the playwright configuration file and implement the function that will generate a state file name concatenated with a timestamp. Otherwise, if an hour does not pass, it will return the old one:

Next, we should check in globalSetup file if the state file exists and if it is, we should not authenticate again.

And our adventure comes to an end here. We configured the e2e testing setup with the playwright, added an authentication scenario, stored the state and cached for reuse purposes.

Useful Links

Hope you’ve enjoyed the article and writing e2e scenarios with the playwright! Thank you for reading!

Build composable frontend and backend

Don’t build web monoliths. Use Bit to create and compose decoupled software components — in your favorite frameworks like React or Node. Build scalable and modular applications with a powerful and enjoyable dev experience.

Bring your team to Bit Cloud to host and collaborate on components together, and greatly speed up, scale, and standardize development as a team. Start with composable frontends like a Design System or Micro Frontends, or explore the composable backend. Give it a try →

Learn More