Thanks for this, I have been using network checks to reduce the waits for elements on the page. In my scenario, I wait for a response from the Api that populates the screen and then start interacting with the page. If I don't have this check the test is flaky that Playwright tries to interact with elements that are still getting populated. This seems to work, but it seems navigation from one page to the next is a bit broken, since the page I navigate from needs to know about network traffic to instantiate the page we are going to. I am wondering if there is a better pattern.
It's hard to give advice without knowing the specifics. But generally it's always better to wait for a certain UI state and network waiting should be the last resort. Maybe there's certain data that shows up eventually? When you think of it, users also don't wait for a network request. They just click around, try to be user-first always. :) I hope this helps. 🦝
Hi, thank you for the great lesson. I wonder If you could make a video on how to write a test for Adobe Analytics and Google Analytics (dataLayer) requests, which fire on page load and clicks. How to verify the values in the payload of such requests.
Great video! What would happen in a scenario where the api doesn’t get called or it returns an error (ie. Never resolves with success) will it just hit the test timeout?
Great question! Your assumption is correct and the error handling depends on your project configuration. `waitForResponse()` has a timeout setting to limit the waiting for a particular API response. If this setting isn't set, the general test timeout will be hit eventually. :) It's up to you and the project requirements to find what works best.
Have you ever encounter this issue: when implementing tests and running locally - everything is ok with "waitForResponse" and test is passing, but when it's being executed in CI (in our case in GitLab) - it throws a timeout exception on this waiting? What could be a reason of that?
Great question. I've never encountered a PWT issue and it's almost always an environment difference. The only way to find out is debug the network and application state via trace files. :) Hope this helps. :)
In this situation, the described approach wouldn't work well. But can you describe the scenario you're trying to test? Because I can't think of a case when it would be impossible to attach the network event handler. 🤔
@@ChecklyHQ Thank you for your attention. I require certain metadata from the app that will be captured with every full page load. I need this information to develop test cases. While I can obtain this metadata by either moving a global variable or invoking the metadata API, my objective is to accomplish this without directly modifying the app's code.
Hey I have a scenario where I need to click on next button and there is navigation happens which sometimes takes more than 15s and I need to do some assertions but these navigations provides a lot of intermittent issues. Is the issue because of API calls. Please guide me on this
Ideally would check if you could work around these without listening for the network (users wouldn't watch and check the network either). So if you're having a long lasting navigation you could increase the timeout for the assertions / actions on the slow page. :) The overall recommandation is to only listen to the network when you really have to. Hope this helps.
