Відео

Good to know, I might give it a try one day. That said I'm not convinced that feeding LLMs application code is the best approach to create e2e test code. A video covering this topic will drop eventually. 🦝

You could still have a single "setup" project in which you write and create different storage state files. You can do this similar to how it's shown in the video for a single user. Then you could define different projects ("User A project" and "User B project"), both relying on "setup" being a dependency but reading in the particular storage state file. "User A project" could rely on the storage state "user-a-state.json" or whatever. Then you could control what files will belong to which project (and as a result to which user) by specifying `testMatch` on the project level (playwright.dev/docs/api/class-testproject#test-project-test-match) Here's an untested example. ``` projects: [ { name: "setup", use: { ...devices["Desktop Chrome"] }, testMatch: /.*\.setup\.ts/, }, { name: user-a", use: { storageState: ".auth/user-a.json", }, testMatch: "*/user-a/*.spec.ts", dependencies: ["setup"], }, { name: user-b", use: { storageState: ".auth/user-b.json", }, testMatch: "*/user-b/*.spec.ts", dependencies: ["setup"], }, ], ``` Does this make sense?

@@ChecklyHQ Thank you so much. I will try this out. My set up is little more complex. I need to run all the tests in Desktop And in Mobile. If I follow the above suggestion, I will have to set up multiple user A desktop and user A mobile?

@ No, you should be able to have User A and User B but than would have 4 projects: - User A desktop - User A mobile - User B desktop - User B mobile But, of course, there are multiple ways to do things, but that's how I would start without seeing code. 😅

Heyooo. 👋 Yes, it's been on the list already but I can't promise when/if we come to it bc it's quite a heavy investment. What real-world project do you have in mind?

Happy to hear the video's been valuable. 💙

Heyooo. 👋 I'll put it on the list, but, unfortunately, it's unlikely we'll cover cucumber. :/

It was FiraCode iScript and you can read about my editor setup here: www.stefanjudis.com/blog/how-to-enable-beautiful-cursive-fonts-in-your-vs-code-theme/

Thanks for watching! 🦝

To be honest, I haven't tried class inheritance with the shown `@step` decorator trick, but theoretically, this sounds reasonable (if POMs are your thing). Did it work at the end? 😅

You bet! 💪 Here's a video describing the concept and abstracting it away with fixtures. Showing this would have just been too long for a YT Short. 🫣 ua-cam.com/video/LKMwS_u_x8Y/v-deo.html

@@ChecklyHQ cool! thank you!

Hmm... I'll have to do some reading about this. What's a PO Manager? 😅

I just checked the docs (playwright.dev/docs/api/class-testinfo#test-info-attach) ad there's no `description` option right now. The only thing I could think of is reusing the name with a short description.

​@@ChecklyHQ I got it in a different way than I needed. However, my more important request is to ignore all the logs and only display the necessary ones. How can I achieve that? For example, when I'm creating a candidate, I will have around 10 lines of code, such as filling the username, DOB, mobile number, and so on. Then, at the end, I click the save button and check whether the candidate is created or not. In this case, I only need to show logs for: Before filling in the candidate details(with screenshot (that i will take care) After filling in the candidate details(with screenshot (that i will take care) The final log showing whether the candidate was created or not (including a screenshot) I want to display only these logs, and hide or ignore the others. How can I achieve this?" FYI already achieved by showing screenshot but not able to ignore the not needed logs that alone how to achieve?

I'm sorry, but you lost me with this explanation of what you're trying to do and/or log. 😅 But I think we already answered the initial question, did we?

Right? 😅

Hey there, I'll put it on the list, but I don't think it'll happen soon, because this isn't a space Checkly will be investing in. And this is the Checkly channel after all. :)

@@ChecklyHQ : Sure....Thanks for the response. In the meanwhile can you share some reference to try this out.

Unfortunately, I don't have experience with testing Chrome extensions or crypto. So I can also onl google things. :/

I 100% agree. If an application has a poor user experience under slow network conditions, this is a problem and should be fixed. In the real world, though, and especially when testing and development are different teams, improving the Frontend is rarely prioritized. It's the typical "works on my machine" and often, people state the "Playwright is too fast" argument, completely ignoring that the issue often is poor hydration patterns or a broken app under slow network conditions. `toPass` and other ways to come around test flakiness are workarounds for symptoms and not addressing the root course. But sometimes it is how it is. :) So you're 100% right.

Thanks! I'm not sure I understand your question entirely. What tests should run in which browser when? 😅

​@@ChecklyHQ Let me rephrase it : I would like to avoid some tests to run on multiple browsers (= 1 project for each) at the same time. So even if workers are available, it would wait for the same test on the previous browser to finish

It's very hard to discuss this topic without looking at specifics. But as an easy way, you could always run tests using the `--project` flag or some grep pattern. Then you'd be in full control of what projects / tests run when. :)

Happy to hear the video was valuable. 💙

That's right - great comment! Having something like this set up as production monitoring is definitely valuable but it comes very tricky very quickly because checking all links can take quite some time depending on the amount of pages. And surely it'd be great to keep track and collect all checked links. But I'm sure there are tools on GitHub that allow you do run things in a cron job. I might extend the example at some point but the video was already long enough. 😅

Great call. I forgot about it because it seemed obvious to me that session data invalidates over time. I adjusted the pinned comment. Thanks.

Checkly is all about enabling developers to test and monitor their preview and prod environments with Playwright. We allow you to run your existing Playwright tests from anywhere and on a schedule. The default and "works out of the box" features require an accessible URL, though. (There might ways to work around this with our private locations feature but I haven't seen someone spinning up a dev-server on localhost with them yet) So for what you describe, unless you spin up a public tunnel to your described dev server, Checkly checks can't test or access your "private app" The Playwright tests run in arbitrary AWS locations at the end of the day. 😅 That said, we do believe in production testing and monitoring because it's the only way to reliably know that production is really up'n'running. Spinning up your app locally with prod config is good test for the new code or feature regressions, but there could still be plenty of things going wrong in prod. With Checkly you can take your existing tests run them on preview deploys and/or prod, but then once you release, run the same (or a subset) of your PWT tests in an interval to really be sure that everything's working at all times. If something's off, you'll receive a proper alert to be able to react quickly. I hope this answer makes sense and happy to explain more. :)

I can't tell what's causing your issues but to find out you should turn on traces (playwright.dev/docs/trace-viewer-intro#recording-a-trace) and inspect what's happening in your CI/CD environment. :) For me, it's a different configuration or network condition most of the time. Good luck!

Yes, we'll all have to see if and how usefull it'll be. I'm game for a11y driven features, though. :)

I'm actually doing the same in one of my projects for parallel CI/CD runs using existing data. The worker id connects to a certain predefined user account (1 to 4 in my case). Unfortunately, I didn't come across a better solution yet, tbh. But I think it's alright. 🫣

@@ChecklyHQ Thanks.

Hard to tell, but happy you figured it out. :)

Thank you. May I ask what's your case for `page` in an after all hook? (Oc, I might look into it for another video 🫣)

Deletion/cleanup from UI.

Happy to hear it's been valuable. 🦝 💙

Thanks. :) Not sure I agree though. There are better tools than serial mode for debugging (UI mode, debug mode and traces) and there are scenarios when tests require to run sequentially in CI/CD. If the tests (for whatever reason) rely on each other or conflict with each other with shared state, then CI/CD might need to run in "serial" or "default" mode.

@ChecklyHQ thanks for the clarification. 👍

Happy to. :)

Could you describe a bit more, what you're stuck at?

@ i cant find a simple tutorial how can i share to a slack channel my test results each test run… all I know atm is i would need to use slack api and slack bot but idk where to start :/

Gotcha. I'll put it on the list. :)

@ thank you so much😭 looking forward to it!

I think it depends on your CI tool. I am using Github actions plugin, for other tools would be a bit different but similar

Precisely - this is where POMs fall short big time. For any somewhat serious product, the number of different page objects gets out of hand very quickly. :) And you're 100% right, there's no silver bullet, and there will never be one. 🦝

Happy to hear that the video has been valuable! 🦝

Short answer: yes. 🦝 👉 playwright.dev/docs/api-testing#reusing-authentication-state

Happy to hear the video was able to help you out. 😉🦝

Thank you! Great comment and you're correct. We have another video about it -> ua-cam.com/video/E8JLQoCDUcU/v-deo.html Let me add a pinned comment and highlight the newer and better way for all the viewers.

Usually I prefer to group functionality based on user actions instead of pages. I also don't like to initialize new page objects all the time. 😅 As an alternative, I quite often have `user.login`, `user.logout`, ... object methods which I bring in via Playwright fixtures. This objects aren't necessarily bound to specific pages but rather a set of functionality. Of course, this approach is no silver bullet but I like it better than POMs. :) I'll put this topic onto the list of ideas for future videos. Thanks!

I'm sorry but I'm afraid I don't understand. To execute code before all tests you could rely on PWT projects or global setup/teardown: playwright.dev/docs/test-global-setup-teardown Could you explain a bit more what you would like to see a video on?

Unfortunately, we can't help with individual issues. But 5min init time indeed sounds very wrong. In these cases, trace files and UI-mode are a big help to indentify what's taking so long. Good luck!

Yes, you can also overwrite the default `page` fixture by using the same name. :)

I'm not sure I understand. Could you rephrase the question and give more explanation of the security context?

Great request! 💯 You can find a similar prompt in this blog post: www.checklyhq.com/blog/chatgpt-vs-playwright-codegen/.

It's my own custom theme and you can find instructions here: www.stefanjudis.com/blog/declutter-emojify-and-prettify-your-iterm2-terminal/#my-custom-theme

Thanks for still being around! 💙

I'm curious. Do you really go TDD for end-to-end tests? Seems unlikely to me.

​@@ChecklyHQ we don't say TDD anymore, it's test first now, to overcome rejections ;) For playwright i would say BDD rather than TDD if really have to. Does not need to be end-to-end (e.g. api snapshots come to mind) Since I prefer gherkin over POM (or better POM used by gherking) i start with the feature every time, yes! From there it depends, sometimes whole failing test, sometimes i go as far as i can/ know and then just set to skip as todo indication. This forces me to actually think before I write prod code (an acient technique not many developers know anymore) But you are right, i would now love to correct myself " lures you into thinking about tests after the implementation, rather than before"

@@M1stFink Who's "we" when you say, "we don't say TDD anymore"? Happy for you that you also start with tests when going for end-to-end testing. :) I like the approach for anything quick, but, as said, for UI tests, it doesn't feel great to me. :)

@ChecklyHQ what exavtly do you mean with end-to-end? I think we are talking about different things/scales here

End-to-end for web apps is anything that spins up a browser uses an application that's running an entire stack for me. So it's testing frontend, backend, and infra end-to-end. :)

It's on the list, yes! 💪

Yea I will waiting for 😊

Thank you for watching! 💙