This thread is trying to answer question "Is 'await page.waitForLoadState('networkidle')' considered a bad practice? Why? What would be the workarounds for this approach?"
Depending on the application under test it would be a valid solution. In some cases, you will see that the networkidle never happens or fires but the page is still not interactable. So, although it is not a perfect solution it may be a tool for some cases. In the other 2 options you will need to address what is the best solution for the scenario. I have found in most cases I wait for a network response, this in my case is checking if the user is authorized to use an element on the page. Even this approach is not fool proof. So to answer your questionn is it a bad practice? No, in some cases it is fit for purpose, but will not be helpful in all testing scenarios. I am a bit on the fence, because I tried it and did not work for me, so others use it so I can't see why it is not another approach to meet your end goal.
I think the right word is discouraged
, not exactly a flat out bad practice. Ideally, as mentioned, you should make it more deterministic by waiting for a specific network call instead.
If you leverage networkidle
, you'll always be waiting for at least 500ms without any network calls, which might be way more than you need. Also, in very dynamic web applications, this might introduce flakiness as sometimes (or very often) you might not actually have a period of at least 500ms without calls.
Rayrun is a community for QA engineers. I am constantly looking for new ways to add value to people learning Playwright and other browser automation frameworks. If you have feedback, email [email protected].