Imagine this: you’re running your Playwright tests, and one of the most common actions is logging in. You’ve written the login flow multiple times for different tests. It works, but it’s redundant, and every time it runs, it eats up valuable test time.
Sound familiar?
As tests grow, especially in larger projects with many dependencies, this becomes a real issue. You end up with repetitive login code, making your tests slower, harder to maintain, and prone to errors.
Now, what if there was a better way?
What if you could set up your login once, and then reuse it across multiple tests, no matter the project dependencies?
That’s where global setup in Playwright comes in.
By reusing login logic and setting it up globally, you can save time, avoid repetition, and streamline your tests.
Overview
Benefits of global setup in Playwright:
- Reduces redundancy by centralizing login/setup logic
- Speeds up tests by running setup only once
- Keeps tests clean and maintainable
- Ensures consistency across tests
- Saves resources by minimizing repeated actions
- Eases scaling as projects grow
- Reduces CI pipeline time
This article explains how to use Playwright’s global setup and project dependencies to reuse login sessions, speed up tests, and streamline authentication workflows.
Why Reusing Login Across Projects Matters?
Authentication is often one of the slowest interactions in any application, involving multiple redirects, API requests, and potential 2FA or SSO constraints. When repeated across dozens of files, these delays accumulate quickly. Large enterprise suites frequently contain hundreds of login-dependent tests, making repeated login a costly operation.
Experts in automation engineering frequently emphasize minimizing repeated setup. Shared authenticated states cut execution time dramatically, especially in suites where over half of tests start with login.
Reusing login across projects helps eliminate redundant overhead and creates a more efficient and predictable test flow, especially in CI/CD environments where consistency is critical.
Understanding Playwright’s Global Setup Feature
Global setup in Playwright acts as a pre-test execution step. It runs once before any test file begins, making it ideal for establishing an authenticated session that can be reused across projects.
Instead of logging in repeatedly within each test, the global setup simulates a single login, saves the storage state, and allows all dependent projects to reuse this file.
This stored state includes:
- Cookies
- LocalStorage
- SessionStorage
- Authentication tokens
By centralizing authentication here, the suite gains both speed and reliability.
Benefits of using global setup in Playwright
Here are some of the benefits of using global setup in Playwright:
- Reduces Redundancy: Avoids repeating login and setup logic across multiple tests.
- Improves Test Speed: Speeds up tests by running setup (like login) once, instead of before every test.
- Cleaner Code: Keeps tests simpler and more maintainable by centralizing setup logic.
- Consistency: Ensures a consistent environment across tests without needing to repeat setup steps.
- Saves Resources: Minimizes repeated API calls or login actions, optimizing test execution time and system resources.
- Easy to Scale: Makes it easier to scale tests as projects grow by reusing global setup for various test suites.
- Faster CI Runs: Helps reduce the overall time of continuous integration (CI) pipelines by reusing global setup.
When global setup is combined with BrowserStack Automate, these benefits extend beyond local runs—shared authentication, test data, and environment state stay consistent across real browsers and parallel cloud sessions.
Configuring Global Setup for Authentication Flow
A typical global setup automates the login path and stores authentication details in a reusable JSON file.
// global-setup.jsimport { chromium } from ‘@playwright/test’;
export default async () => {
const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto(‘https://app.example.com/login’);
await page.fill(‘#user’, process.env.USERNAME);
await page.fill(‘#pass’, process.env.PASSWORD);
await page.click(‘#login’);
await page.waitForURL(‘**/dashboard’);
await page.context().storageState({ path: ‘auth.json’ });
await browser.close();
};
This file becomes the authentication source for all test projects dependent on it.
Read More: How to Scroll to Element in Playwright
Using project.dependencies to Share Login State
Playwright’s project.dependencies feature allows one project to run first and produce output that other projects can consume. In this scenario, a dedicated “setup” project logs in and saves auth.json, while the remaining test projects automatically reuse it.
// playwright.config.jsprojects: [
{
name: ‘setup’,
testMatch: /global.setup.spec.js/
},
{
name: ‘ui-tests’,
use: { storageState: ‘auth.json’ },
dependencies: [‘setup’]
}
];
This ensures that the authenticated state is generated before any UI test begins.
Persisting Authentication Cookies/Storage in Playwright
When Playwright saves storage state to auth.json, it captures all browser-side data required for authenticated workflows. This persistence replicates how real browsers maintain sessions, allowing tests to skip the login page and land directly on authenticated routes like /dashboard or /profile.
This approach improves performance dramatically and reduces the load on backend authentication services-especially important when running high parallelization.
Handling Multiple Projects and Browsers with Shared Setup
Global setup works not only across projects but also across browsers, as long as authentication is compatible across engines. For applications using standardized authentication (cookies or token-based systems), one login state can power Chromium, Firefox, and WebKit tests.
This multiplies the efficiency gains: a single login supports multi-browser testing without extra overhead.
Best Practices for Secure and Maintainable Login Reuse
To ensure long-term reliability and security, several practices help maintain clean authentication workflows in Playwright.
- Use environment variables for credentials
- Credentials should never be hardcoded in scripts.
- Keep test accounts isolated
- Dedicated accounts reduce the risk of unintended side effects.
- Regenerate login state on each CI run
- Stale credentials can break dependent projects.
- Validate session integrity
- A simple element check after login ensures storage was captured correctly.
- Avoid heavy tasks in global setup
- Authentication should be the only major action performed here to ensure fast, stable execution.
Read More: How to install Playwright
Avoiding Common Pitfalls in Login Reuse and Global Setup
Several issues frequently appear:
- Expired authentication tokens causing dependent tests to fail
- Global setup performing too many unrelated tasks
- Using different login logic across test files
- Conflicting storage state paths in parallel pipelines
Sticking to a single source of authentication truth-global setup-helps avoid these problems entirely.
Debugging Global Setup and Project Dependency Issues
Debugging global setup becomes simpler when using Playwright’s trace capabilities.
test.use({ trace: ‘on-first-retry’ });Trace files reveal whether login succeeded, where failures occurred, and what navigation steps were taken. When dependent tests fail due to missing auth.json, verifying the setup project’s run order and output usually resolves the issue.
Scaling Login Reuse in CI/CD and Parallel Environments
In CI pipelines, global setup reduces the volume of repeated authentication calls and eliminates bottlenecks caused by login endpoints that throttle or rate-limit traffic. Distributed or sharded pipelines benefit even more, as each shard starts with a fresh, verified authentication file.
This consistency stabilizes entire pipelines, particularly when running large suites across containers or virtualized environments.
Why Use BrowserStack Automate for Reused Login and Project Workflows
Reusing login is most powerful when paired with real-device and real-browser execution. Variations in rendering engines, cookie handling, or session persistence can affect how authentication behaves across environments. BrowserStack Automate helps validate these flows at scale.
Key Features of BrowserStack Automate:
| Feature | What It Is | Why It Matters for Login Reuse |
| Real Devices & Browsers | Access to real Android, iOS, Windows, macOS environments | Ensures login sessions behave consistently across actual user platforms |
| Parallel Execution | Run multiple projects simultaneously | Validates authentication reuse across dozens of test groups at once |
| Debugging Artifacts | Video, console logs, network logs | Helps diagnose login failures in global setup or dependent tests |
| CI/CD Integrations | Works with Jenkins, GitHub Actions, GitLab | Ensures smooth authentication reuse in distributed pipelines |
| Latest & Legacy Browser Coverage | Full ecosystem of browsers and versions | Verifies session persistence across different browser engines |
BrowserStack serves as the execution layer that ensures reused login workflows remain stable, regardless of which device, OS, or browser is involved.
Conclusion
Playwright’s global setup, combined with project dependencies, offers an efficient and scalable approach to reusing login sessions across test projects. By eliminating repetitive authentication flows and centralizing session logic, teams achieve dramatic gains in speed, reliability, and maintainability.
When executed on real devices and browsers through BrowserStack Automate, shared login workflows become even more dependable, ensuring consistent behavior across diverse environments and accelerating the entire testing pipeline.
