Creepy I exactly faced this poor hydration behavior on the tested web app few days ago for the first time. What a timing, Thank you for showing that option! 🙏
Another great video; thank you. I’d possibly disagree with the “right fix” advice on Playwright’s docs to disable interactive controls until after hydration though, as that could cause confusion and frustration to screen reader users. They might attempt to interact with an element initially announced as being disabled/dimmed, and when that control was subsequently enabled via hydration then you’d have to manage how to update that state to the screen reader user.
Love this comment! You make a great point. I followed the PWT docs for the sake of the storyline of the video. But I think you're correct. Disabled controls aren't focusable and won't trigger validations - and generally in the UX/a11y community it's advised to not disable controls for these reasons. But yeah, the topic of poor hydration + disabled controls is probably for another day and/or video. Thanks! 💙
@@ChecklyHQthank you. It was more of an end-user issue I was highlighting (not necessarily Playwright operation); that it’s not great to set out a page as having x elements non-operable and to then amend that, as it’s something that then possibly has to be managed so the screen reader user is aware they can use those elements. It might be edge-case; that the page will hydrate and elements are enabled before a screen reader user attempts to use those elements, but it might be more of-a-thing in things like modals (where you often have a button default-focused).
Hello! I really appreciate that. Could you please create a video list focused solely on fighting flakiness in testing? This is a critical area for all testers.
I am new in test automation, and I needed to test redirects after page reload, so I used await page.waitForLoadState('load'); await page.waitForTimeout(500); await page.reload(); await page.waitForLoadState('load'); await page.waitForTimeout(500); await expect(page.locator('.product-card-wrapper').first()).toContainText('PLN'); but .toPass() is much faster and stable, thank you a lot
Hah - that's a great question! For this example I only delayed adding the event listeners via a `setTimeout`. 🫣 But the same problem could appear because of various reasons. :)
Unfortunately this solution works 50% of the time. I used it in 2 tests, in one of them it works, and in the other it doesn't. I have 2 assertions inside (toBeVisible and toHaveText) followed by page reload. The 'page reload' part is not executed for some reason... I had to wrap it in try-catch block, with 'expect' part inside 'try', and the page reload inside 'catch'
I was stuck on how to resolve this issue for too long. Thank you for saving my sanity
You, sir, are a gentleman and a scholar. Also, you've given me fuel to scold our front end team!
Happy to hear that!
I love this tip. I have had so many banging-head-on-wall moments with this type of problem and trying to avoid adding Time.Delays. Thanks for sharing.
Yes, 100%. If the frontend is untestable I usually reach for `toPass()` first. 💪
Creepy I exactly faced this poor hydration behavior on the tested web app few days ago for the first time. What a timing, Thank you for showing that option! 🙏
Great! 🎉 Happy this video came at the right time. Let us know how it goes. ;)
To further this incredible timing I literally ran into this issue today! Great vid thank you Checkly!
@@lfc67671Yay! 🎉
Thank you. this saved my running tests in playwright automation project 😀😃
Whoop whoop! 🎉
Thank you again~ I faced this issue this morning, and you saved me again.
Oh it helps a lot! Our product is basically made of hydration problems.
Yeah - I'm used to this state, too. 😅
Thank you again, nice tip! Did not know about it. Big thanks, that you are sharing it with community!
This appears to be a better workaround than Webdriverio where I struggle with. This is very helpful in my case. Thanks for sharing!
Yeah, testing poor hydration is tricky, but this turned out to be valuable for me. Happy the video was helpful!
Great video.
This is really helpful in my daily work. Thanks for sharing this.
Another great video; thank you.
I’d possibly disagree with the “right fix” advice on Playwright’s docs to disable interactive controls until after hydration though, as that could cause confusion and frustration to screen reader users. They might attempt to interact with an element initially announced as being disabled/dimmed, and when that control was subsequently enabled via hydration then you’d have to manage how to update that state to the screen reader user.
Love this comment! You make a great point. I followed the PWT docs for the sake of the storyline of the video. But I think you're correct. Disabled controls aren't focusable and won't trigger validations - and generally in the UX/a11y community it's advised to not disable controls for these reasons. But yeah, the topic of poor hydration + disabled controls is probably for another day and/or video. Thanks! 💙
@@ChecklyHQthank you. It was more of an end-user issue I was highlighting (not necessarily Playwright operation); that it’s not great to set out a page as having x elements non-operable and to then amend that, as it’s something that then possibly has to be managed so the screen reader user is aware they can use those elements. It might be edge-case; that the page will hydrate and elements are enabled before a screen reader user attempts to use those elements, but it might be more of-a-thing in things like modals (where you often have a button default-focused).
Hello! I really appreciate that. Could you please create a video list focused solely on fighting flakiness in testing? This is a critical area for all testers.
This is a great idea and I'll come to this in the upcoming weeks. I'll let you know here.
I am new in test automation, and I needed to test redirects after page reload, so I used
await page.waitForLoadState('load');
await page.waitForTimeout(500);
await page.reload();
await page.waitForLoadState('load');
await page.waitForTimeout(500);
await expect(page.locator('.product-card-wrapper').first()).toContainText('PLN');
but .toPass() is much faster and stable, thank you a lot
Yay! Happy the video has been valuable. 💙
Thanks nick, you give an idea to solve an issue with await page.waitForTimeout(500);
This is gold !! Thanks for the tip.
Happy it's useful! 🦝
Fantastic video! I'm curious: how did you create the demo app to force a hydration error for your test to fall?
Hah - that's a great question! For this example I only delayed adding the event listeners via a `setTimeout`. 🫣 But the same problem could appear because of various reasons. :)
Great video and explained very clean. Thank you!
Glad it was helpful!
That's really cool - I love Playwright 😍😍
great explanation!
Glad it was helpful! 💙
Super nice !!
Thanks. Happy it's been valuable. 🎉
Crack! Im going crazy whit flakynes and you give me the solution
Yay! That's great to hear!
cool
Unfortunately this solution works 50% of the time. I used it in 2 tests, in one of them it works, and in the other it doesn't. I have 2 assertions inside (toBeVisible and toHaveText) followed by page reload. The 'page reload' part is not executed for some reason...
I had to wrap it in try-catch block, with 'expect' part inside 'try', and the page reload inside 'catch'
Happy you figured it out. :)
Thanks for the awesome video and tips! Keep up the good work
Thanks for the kind words. Happy the videos are valuable. :)