1

I'm currently working on a java selenium Project, which is usually a small script where I have to check for each element for it's presence and based on that some actions are triggered but our main concern is time duration to finish the script.

Basically I have used each one from below in my script and ran the test, though in each case script was running but I find very little speed improvement in script execution duration.I'm using wait

driver.manage().timeouts().implicitlyWait(10000,TimeUnit.MILLISECONDS);

and along with it

!(driver.findElement(By.xpath("Element Xpath)).isEmpty()) 

or

driver.findElements(By.xpath("Element Xpath)).size()>0

I know I can go for CSS Selectors but in my case that is not feasible due to DOM Tree structure. what can be used instead of

driver.findElements(By.xpath("Element Xpath)).size()>0

this to check if element is present or not and based on that I have to trigger multiple other actions.

1 Answer 1

1

avoid using Xpath

Think before you try xpaths Xpath identification is generally slower than other forms of object identifications.

Another way to quickly get feedback from tests is to run them in multiple categories. Break the tests into categories according to the functionality or by nature of the tests

Smoke test - the tests needed to ensure that critical functionalities(i.e business & technical behaviors) are intact.

Regression tests - the tests which cover all other workflows.

As you mentioned that you have to check for each element for it's presence and based on that some actions are triggered so limit time to wait it that's how you can speed it up

Trying to go headless test

Custom Fluent wait Code Example:

browser.manage().timeouts().implicitlyWait(0);
browser.wait(function () {
    browser.sleep(1000);
    return element(by.id('id1')).isDisplayed()
    .then(
        function (isDisplayed) { 
            return isDisplayed; 
        }, 
        function (error) { 
            return false 
        });
}, 20 * 1000);

Remove redundant test steps in between tests(this is the biggest time saver)

Don't use UI tests to create/setup test data(use APIs to seed data), use UI tests to validate end-user business scenarios only.

Don't use shared(like with developers/business analysts/not even with manual testers)/or production replica(heavy) database .Use dedicated light QA automation database with carefully designed baseline data only.

Restore/refresh database before runs to keep it clean & light.

While designing test cases, eliminate unnecessary long UI steps and let the tests focus only on test validations with least page navigations

or refer this

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.