I've been running automation tests that execute relatively quickly in my local environment but are extremely slow in Sauce Labs.
The existing Java code appears to have two types of redundant page loading wait times
//1. set at the beginning of the test
driver.manage().timeouts().pageLoadTimeout(40, TimeUnit.SECONDS);
//2. called before every UI interaction/assertion
(new WebDriverWait(wDriver, waitTime)).until((wDriver) -> {
return javascriptExecutor.execute_script("return document.readyState").equals("complete")
});
Is the pageLoadTimeout a type of implicit wait that might be causing a conflict with the second "document.readyState" explicit wait?
Is this entirely redundant, or are there any edge cases where one of these checks might not work, and the secondary method acts as a backup?
Any help is appreciated AJ
There are two different concepts here. The first is that with w3c you can now set a Page Load Strategy in the capabilities at the beginning of a session. This affects what Document readiness state the driver will wait for before returning control to the user. If the specified readiness state is not satisfied before the page load timeout, the driver is supposed to return an error.
Note that both of these things only apply to navigation events, so clicking an element that results in a page load should not trigger these.
To complicate things one more level, Chromedriver has an open bug for incorrectly:
wait[ing] for navigation to complete at the end of almost all commands
So for right now Chrome tests actually will wait for the specified document readiness state on clicks.
Finally, remember that for today's web there is typically a lot of content loaded dynamically via JavaScript, so even when the document readiness state is "complete" the DOM is unlikely to be in it's final state, which is why you are encouraged to use explicit waits for the things you actually want to interact with.