Do we have a set of selenium code to improve page loading in browser so that test page loads faster while under test? It would be of great help while automation testing is in progress. Would like to thanks you advance for solution, any short cut or feedback.
Its unlikely you will be able to reduce the time to load a page (it is more likely the developers would need to make changes to enact this).
However there are various ways to optimize your test cases, in particular around avoiding waits. This will in turn mean your tests complete quicker.
If you are looking to test that something is NOT present for example, then using the below would need to wait until the page is rendered and then a full timeout before returning a result (implicit wait).
assertFalse(isElementPresent(PageElements.PDFLinkText),"PDF link present when not expected");
List pdfslinks = driver.findElements(By.className("PDFLink"));
findElements() does not wait, but returns list of elements (located by locator). If List is empty if nothing is found. This is an Explicit wait.
This change alone improved the speed of each test by 20+ seconds.
One general approach that could be taken is to figure out which tests could share a browser instance.
Frequently (and usually ideally) each test opens up a new browser instance and this approach avoids data from tests interfering with each other.
This can also be used to share some activities, most frequently login authentication, e.g. one section of shared code opens up a browser instance and logs in and then the subsequent tests in that group continue to use that logged in browser instance.
As I mentioned this is a non-standard approach and is NOT a good practice. This can lead you to tests that interact in unpredictable ways with intermittent failures. However sometimes speed needs can over-ride that. As with all 'rules', break with caution when needed.
One often overlooked approach is to reduce the number of tests being run. TDD and BDD development often leads to test creation, but RARELY to test deletion. I don't mean when code is deleted, tests should be deleted - that's certainly true in itself - but I mean that sometimes it's just a good idea to:
- delete tests that never fail
- delete tests that fail intermittently but pass most times
- delete tests that aren't appropriate for the platform*
- change scheduling so that not all tests are run all the time, e.g. some are daily
* for example I recently found a test suite of 50 tests that was running verfy slow on mobile. It turned out that 34 of the tests were intended for desktop only - but passed on mobile as the DOM still works. So I removed them for a > 50% reduction in test suite time.