[Question] Way to skip global setup for selective tests?

[AmareshKulkarni]

My application has account signup workflow and a number of workflows after user logs in. Following the documentation, I was able to use global setup for authentication and re-use across all tests. However, I don't need authentication for the actual account signup flow.

Is there a way to skip global setup that involves login for the account signup tests or conditionally execute global setup if the test being run is account signup related?

[yury-s]

Is there a way to skip global setup that involves login for the account signup tests or conditionally execute global setup if the test being run is account signup related?

Global setup runs once before all tests. Do you run authentication and signup flows in one and the same project?

You can try something like this to only load authenticated state in the tests that require authentication and not load it for signup ones. Will it work?

[AmareshKulkarni]

Thank you for the quick turnaround.

The link provided looks like is for a situation when a user needs to be logged in multiple times (per role), but in my case, it is more like the user may not even exist. They will start with the sign-up, and then move onto login to perform various other functions.

I can run them (signup and sign-in) in separate playwright projects, but they are both in the same codebase. Is there a way to configure the global setup per playwright project? Or another alternative is to get the name of the project being run in the global setup, so that I can conditionally execute the login logic. Either of these options could work for me, could not find a reference for guidance.

The last option probably is to completely isolate codebases for sign up and sign-in into separate code bases, but I am worried that would just add additional effort in maintenance.

[yury-s]

It is one globalSetup per config currently. No per-project options and project name is not available to the globalSetup (note that you single playwright run may execute multiple projects). You could split your config into two with two different global setups, it is somewhat inconvenient though.

[AmareshKulkarni]

Thank you. I will for now use a different configuration file for signup flow

-c or --config : Configuration file. If not passed, defaults to playwright.config.ts or playwright.config.js in the current directory.

[aslushnikov]

@dgozman global fixtures should help here.

[evanfuture]

I did it this way:

const context = await browser.newContext({ storageState: { cookies: [], origins: [] } });
  const page = await context.newPage();
  await page.goto('/');
// auth context removed

[evanfuture]

Found an even easier way, just drop this into your describe block or above your tests: test.use({ storageState: { cookies: [], origins: [] } });

[sowji-elligo]

@evanfuture This worked for me, Thanks!

[DanielStoica85]

Found an even easier way, just drop this into your describe block or above your tests: test.use({ storageState: { cookies: [], origins: [] } });

But this will still run the globalSetup once before your tests, no? Just that it won't use what's inside storageState.json file anymore.

[evanfuture]

But this will still run the globalSetup once before your tests, no? Just that it won't use what's inside storageState.json file anymore.

Yes, exactly. The idea is that you will want to use the globalSetup far more often than to not use it, so this works as a compromise.

[Camo30]

@yury-s Is there a reason why

test.use({ storageState: undefined });

does not act like

test.use({ storageState: { cookies: [], origins: [] } });

I thought the first would also override the storage state from global configuration but that does not work. I would prefer the first one because it is even shorter. Are there other use cases for undefined?

[pavelfeldman]

Why was this issue closed?

Thank you for your involvement. This issue was closed due to limited engagement (upvotes/activity), lack of recent activity, and insufficient actionability. To maintain a manageable database, we prioritize issues based on these factors.

If you disagree with this closure, please open a new issue and reference this one. More support or clarity on its necessity may prompt a review. Your understanding and cooperation are appreciated.

[Silverium]

I have another case that could be studied.

Environment

• I have 3 different accounts with different roles.
• I use the vsCode extension

Flow

I run a specific test for the first time, which has as a dependency the auth.setup.ts file. It saves the needed storageState for each of the three roles.

Second time I run the specific test, the storageState could be reused, and all auth.setup.ts tests are in fact overwriting the existing files.

Expected

Conditionally run the auth.setup.ts if storageState files are already present. Or at least in some way to be able to skip them from the vsCode interface.

Workaround

Of course, we could setup an env file to add or remove the dependency:

// playwright.config.ts
  projects: [
    { name: 'setup', testMatch: /.*\.setup\.ts/ },
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
      dependencies: !!process.env.SKIP_SETUP? [] : ['setup'],
    },
...

But maybe there is some more elegant way to do that?

[dgozman]

@Silverium You can manually check that fs.existsSync(storageStateFilePath) in the auth.setup.ts and just return from the test function. If that does not work, please file a new issue so that we can take a look.

[Silverium]

@Silverium You can manually check that fs.existsSync(storageStateFilePath) in the auth.setup.ts and just return from the test function. If that does not work, please file a new issue so that we can take a look.

That's indeed faster and a less messy DX.

Now when the developer wants to re-write the files generated in the auth.setup.ts, it will be enough to delete the .auth folder (with the files inside) or any of the generated files.