Quick comment after releasing this video: you can and should only reuse session / login data when your tests aren't modifying the existing user. Otherwise, your tests will conflict with each other. In these scenarios, it's better to create a new user for each tests.
Neat way to reuse logged-in state, when you don't create unique users for each test and can't (or don't want to) auth via API calls! Great content! Thanks 👍
I am working on an application where the login flow is not based on the user's input. Instead the user is redirected to an Okta auth page which internally uses kerberos and eventually redirects the user back to the application. The redirect logic and local storage update is handled by Okta auth js and okta react packages. In this scenario, how can I stub my auth state to a temporary json file? When I try to run my tests, the auth flow breaks as Okta server doesn't recognize the user when the application is running via playwright's browser.
Heyoooo. 👋 Unfortunately, I haven't tested this flow yet and neither do I have a quick test setup to play around with it. So, unfortunately, I can't give guidance here. :/
@@ChecklyHQ I have test cases need to be interacted between user and admin in one test. This is how I set it: const adminContext = await browser.newContext({ storageState: '.auth/admin.json' }) const adminPage = await adminContext.newPage()
const userContext = await browser.newContext({ storageState: '.auth/user.json' }) const userPage = await userContext.newPage() await adminPage.goto(commonData.stgUrl) await userPage.goto(commonData.stgUrl) But I need to paste it on each test, that is my issue. Hope that you give a suggestion
Great video, everything worked like a charm! Quick question, could you theoretically use similar logic to store login state when running the scraper in a production environment with Playwright Library?
I haven't tested it, but it should work the same when using the Playwright lib. :) The only thing to keep in mind then is that you'll have to run the setup script (it's done via projects in the video) somehow yourself. :)
@@ChecklyHQ I can confirm this works! I took the following steps: 1. Created an async function called login.js that returns the cookies, or sets and returns them if needs be - it's important to make sure this is just a normal async function, not a self invoking one 2. Created an async getCookies function to handle the cookie logic for cleanliness. It's just a try catch statement that either returns the cookies array or an empty array 3. Call the async login function in my index.js file on each run, so now it's able to handle the cookie logic depending on whether the cookies array is empty or has length Perhaps there's a dryer way to do this with browser contexts etc but I'm a little new to this. Everything seems to be working fine tho so I'll optimise at a later date! Thanks again for the tutorial-couldn't have reached here otherwise!
I'm sorry to hear that. Without additional info and example code, it's impossible to help, though. You can check the working example on GitHub: github.com/checkly/playwright-examples/
I have 7 tests to run, after using this, first, it's taking only 4 workers instead of 7 workers, and after that, the other 3 workers started. Do I need to change anything?
What are you `fullyParallel` and `workers` settings? By default, PWT tried to parallelize as much as possible. The `dependency` setting shown in this video only controls the order of projects run. :)
I can create the storage using setup, but it's not passing to next test. In the browser, it was showing" about:blank". But on your video pass to another test.
It works until my session is active i .e.if the maximum time for a session is 15 mins . If I try to access my stored. Json file after 15 mins it would show session time out . How to resolve it
I'm not sure if I understand your question correctly, but the session storage to be invalid at some point is expected. In CI/CD it would always run before your tests so it still speeds up your tests. In development you'd have to rerun `setup`.
Did someone try it with auth0, does it work fine? I loose login after a 2-4 tests... UPDATE: works fine, it's just logout of one of the tests cancelled the state (what a surprise) No logout - runs fine
@@ChecklyHQ Thank you for your response! I wanted to clarify-should we include that type of information in the repo as well? Additionally, what would be the best approach to manage credentials securely when using Playwright in a CI/CD pipeline? I’d appreciate any suggestions or best practices you could share. Thanks again!
@@brandonzafiro8449 Sure thing. :) No, you wouldn't put these credential files in your repo and they should live in gitignore. (they'll also expire eventually) In CI/CD, you run the setup step as shown, generate a new credentials file, and your tests will read it to set the state. This way, everything is always fresh and you don't need to check in additional files. I hope this makes sense. :)
Just worth to mention that this method is only viable when you do not change any data on a user or in the system that is shared between tests. In most cases you need to create new user and log in via api.
Quick comment after releasing this video: you can and should only reuse session / login data when your tests aren't modifying the existing user. Otherwise, your tests will conflict with each other. In these scenarios, it's better to create a new user for each tests.
Спасибо за видео и время которое вы потратили на его создание. Вы очень помогли
I cannot imagine that this amazing concept exists! Thanks sir.
Neat way to reuse logged-in state, when you don't create unique users for each test and can't (or don't want to) auth via API calls!
Great content! Thanks 👍
This is useful for login with MFA functionalities.
I am working on an application where the login flow is not based on the user's input. Instead the user is redirected to an Okta auth page which internally uses kerberos and eventually redirects the user back to the application. The redirect logic and local storage update is handled by Okta auth js and okta react packages.
In this scenario, how can I stub my auth state to a temporary json file? When I try to run my tests, the auth flow breaks as Okta server doesn't recognize the user when the application is running via playwright's browser.
Heyoooo. 👋
Unfortunately, I haven't tested this flow yet and neither do I have a quick test setup to play around with it. So, unfortunately, I can't give guidance here. :/
It' great. Could you make a video to guideline "Testing multiple roles with POM fixtures", please?
Could you explain a bit more? Are you asking for an example showing how to have e.g. an admin/user test case? What issues are you facing?
@@ChecklyHQ I have test cases need to be interacted between user and admin in one test. This is how I set it:
const adminContext = await browser.newContext({ storageState: '.auth/admin.json' })
const adminPage = await adminContext.newPage()
const userContext = await browser.newContext({ storageState: '.auth/user.json' })
const userPage = await userContext.newPage()
await adminPage.goto(commonData.stgUrl)
await userPage.goto(commonData.stgUrl)
But I need to paste it on each test, that is my issue. Hope that you give a suggestion
Thanks for the tips!
Thank you, sir!
Great video, everything worked like a charm! Quick question, could you theoretically use similar logic to store login state when running the scraper in a production environment with Playwright Library?
I haven't tested it, but it should work the same when using the Playwright lib. :)
The only thing to keep in mind then is that you'll have to run the setup script (it's done via projects in the video) somehow yourself. :)
@@ChecklyHQ Amazing, thank you so much for the info and quick response! I’ll report back when I cross this bridge 🙏🏾
@@stephena8965 Looking forward to hear back!
@@ChecklyHQ I can confirm this works! I took the following steps:
1. Created an async function called login.js that returns the cookies, or sets and returns them if needs be - it's important to make sure this is just a normal async function, not a self invoking one
2. Created an async getCookies function to handle the cookie logic for cleanliness. It's just a try catch statement that either returns the cookies array or an empty array
3. Call the async login function in my index.js file on each run, so now it's able to handle the cookie logic depending on whether the cookies array is empty or has length
Perhaps there's a dryer way to do this with browser contexts etc but I'm a little new to this. Everything seems to be working fine tho so I'll optimise at a later date!
Thanks again for the tutorial-couldn't have reached here otherwise!
Nice trick, now do it with session storage :3
Haha, while possible with page.evaluate() i'll leave that for another time. 🫣
I did the exact setup but on next load it again lands on login page.
I'm sorry to hear that. Without additional info and example code, it's impossible to help, though. You can check the working example on GitHub: github.com/checkly/playwright-examples/
I have 7 tests to run, after using this, first, it's taking only 4 workers instead of 7 workers, and after that, the other 3 workers started. Do I need to change anything?
What are you `fullyParallel` and `workers` settings? By default, PWT tried to parallelize as much as possible. The `dependency` setting shown in this video only controls the order of projects run. :)
I can create the storage using setup, but it's not passing to next test. In the browser, it was showing" about:blank". But on your video pass to another test.
Without seeing your code unfortunately it's impossible to help. A link to the code is in the description.
It works until my session is active i .e.if the maximum time for a session is 15 mins . If I try to access my stored. Json file after 15 mins it would show session time out . How to resolve it
I'm not sure if I understand your question correctly, but the session storage to be invalid at some point is expected. In CI/CD it would always run before your tests so it still speeds up your tests. In development you'd have to rerun `setup`.
Did someone try it with auth0, does it work fine? I loose login after a 2-4 tests... UPDATE: works fine, it's just logout of one of the tests cancelled the state (what a surprise) No logout - runs fine
Great to hear you figured it out!
How can we handle this on CICD ?
Heyoo. :) Can you expand the question a bit more? This approach should work in CICD without a problem. :)
@@ChecklyHQ Thank you for your response! I wanted to clarify-should we include that type of information in the repo as well? Additionally, what would be the best approach to manage credentials securely when using Playwright in a CI/CD pipeline? I’d appreciate any suggestions or best practices you could share. Thanks again!
@@brandonzafiro8449 Sure thing. :)
No, you wouldn't put these credential files in your repo and they should live in gitignore. (they'll also expire eventually)
In CI/CD, you run the setup step as shown, generate a new credentials file, and your tests will read it to set the state. This way, everything is always fresh and you don't need to check in additional files.
I hope this makes sense. :)
Just worth to mention that this method is only viable when you do not change any data on a user or in the system that is shared between tests. In most cases you need to create new user and log in via api.
That's a great call thank you! And for sure, it depends on the tests and what they perform!
I made a comment and pinned it. Thanks again for this valuable comment!