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.
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. :)
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
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'
Great video.
This is really helpful in my daily work. Thanks for sharing this.
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!
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! 🎉
That's really cool - I love Playwright 😍😍
Great video and explained very clean. Thank you!
Glad it was helpful!
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).
great explanation!
Glad it was helpful! 💙
Crack! Im going crazy whit flakynes and you give me the solution
Yay! That's great to hear!
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.
Super nice !!
Thanks. Happy it's been valuable. 🎉
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. :)
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. 💙
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. :)