logo logo

TestProject Announces New Adaptive Wait Capability

main post image

Did you know? Simple async waits are believed to cause up to 45% of test flakiness and failures. TestProject’s new adaptive wait capability is smart enough to eliminate these errors entirely. Now, your tests can intelligently wait for actions and validations before proceeding with your test. You will never need to struggle with simple async waits or pauses to your test again!

This brand new feature is applicable to all UI tests on TestProject’s free platform, including your tests for Android, iOS and Web applications.

Why adaptive wait?

Waiting is a common requirement of almost any user scenario, to make sure actions are only performed when the proper conditions have had time to appear. However, determining what is a proper waiting time for a certain app is no easy task, even for a skilled engineer.

Why are waiting times so complicated to determine? Our favorite web and mobile applications tend to work differently on different devices and from different locations. Seemingly minor factors such as internet speed or device physical resources may impact the loading time by mere milliseconds, which can compound and cause waits to fail.

Usually, teams will overcompensate in their wait times to ensure that they are on the side of a longer wait time. In turn, this causes test execution times to balloon from minutes to hours, as even the most basic test will contain several waits.

So, to save you time and improve your tests’ stability, we have developed an adaptive wait that knows when to move to the next action, even for the most advanced automation tests in Selenium or Appium. Now, you can trust your tests without having to build in unnecessarily long waits.

How adaptive wait works with TestProject’s recorder?

You can use the adaptive wait functionality within any UI test automation step or validation in TestProject. TestProject will adapt to the actual application loading pace and execute the next action only once the proper conditions are met. As a failsafe, you can set a maximum wait time before the step fails (by default 15 sec) in the step section, so your test will move on to the next step in the case that the conditions are never met.

TestProject Adaptive Wait

You can also edit the adaptive wait time globally for your test from the test’s settings.

TestProject Test Settings

How adaptive wait works within TestProject’s SDK

Even when using TestProject’s Selenium and Appium compatible SDK, you can still take advantage of the new adaptive wait capabilities. So long as you leverage the helper.getDriver() driver instance actions provided by TestProject SDK, TestProject can employ an adaptive wait. This will ensure the element is visible before performing any operation on (eg. click, tap, typeText, etc).

First, you must set the timeout for the adaptive wait driver actions. Then, any action you perform will employ an adaptive wait.

Web Example

In the following web example, we will navigate to a URL and input a username and password in their respective fields. Pay attention to the following parts in the script below:

  • WebDriver driver = helper.getDriver();
  • // Set the maximum threshold for the adaptive wait.
    driver.setTimeout(15000);
// This is the test’s execute method, it will contain the actions taken in the test.
  public ExecutionResult execute(WebTestHelper helper) throws FailureException {
// Leverage the TestProject driver.
    WebDriver driver = helper.getDriver();
   // set timeout for adaptive wait driver actions, by increasing this timeout you increase 
   //the maximum threshold that the driver will wait for element to become visible.
    driver.setTimeout(15000);
// The TestProject reporter.
    TestReporter report = helper.getReporter();
    By by;
    boolean booleanResult;
    //    Navigates the specified URL.
    booleanResult = driver.testproject().navigateToUrl(ApplicationURL);
    report.step(String.format("Navigate to '%s'",ApplicationURL), booleanResult, TakeScreenshotConditionType.Failure);
    // Type the username.
    by = By.cssSelector("#name");
    booleanResult = driver.testproject().typeText(by,"Username");
    report.step("Type 'Username' in 'name1'", booleanResult, TakeScreenshotConditionType.Failure);
    // Type the password.
    by = By.cssSelector("#password");
    booleanResult = driver.testproject().typeText(by,"12345678");
    report.step("Type '12345678' in 'password1'", booleanResult, TakeScreenshotConditionType.Failure);
// Report the test as passed.
    return ExecutionResult.PASSED;
  }

Mobile Example

In the following mobile example, we will use the adaptive wait functionality to wait for an Android Element to appear in a coded test, before tapping on it. Pay attention to the following parts in the script below:

  • AndroidDriver driver = helper.getDriver();
  • // Set the maximum threshold for the adaptive wait.
    driver.setTimeout(15000);
// This is the test’s execute method, will contain the actions taken in the test.
public ExecutionResult execute(AndroidTestHelper helper) throws FailureException {
   // Leverage the TestProject driver. 
    AndroidDriver driver = helper.getDriver();
   // set timeout for adaptive wait driver actions, by increasing this timeout you increase 
   //the maximum threshold that the driver will wait for element to become visible.
    driver.setTimeout(15000);
// The TestProject reporter.
    TestReporter report = helper.getReporter();
    By by;
    boolean booleanResult;
    ExecutionResult executionresult;
Then, any action you perform will employ an adaptive wait, for example:
    // Tap on the element by the locator the ID.
    by = By.id("com.google.android.youtube:id/menu_item_1");
    booleanResult = driver.testproject().tap(by);
// Report the step result via the TestProject reporter.
report.step("Tap 'Search1'", booleanResult, TakeScreenshotConditionType.Failure);
// Report the test as passed.
    return ExecutionResult.PASSED;
  }

What about explicit wait?

With TestProject you can also use explicit waits, which are available for each step of your test as “Step Pause”. You can choose to add an explicit wait time either before or after the execution of your test step.

TestProject Explicit Wait

You will need to set the duration of the wait time in milliseconds.

TestProject Explicit Wait - Set Time

You can also edit this setting globally for each of your test steps by going to the settings of your test and changing the default step pause.

TestProject Test Settings

Advanced Capabilities: “If visible” & “Is visible”

Users have loved the idea of adaptive waits so much we decided to take it one step further, to cover one of the most frustrating causes of unexpected test failures: popups. As test engineers, we have all encountered these UI elements that seem to appear randomly, whether as commercial ads, registration forms, or requests for system permissions. While these popups may appear from time to time and prevent our test from completing, they may not show up consistently enough to count on them.

Do we choose to write an explicit step to close the popup, which then might not appear, causing a test failure? Or do we ignore the popup and not create an explicit step to close it, with the risk that the popup may then prevent our test from continuing?

Instead, we’ve allowed you to create any number of “If visible” actions, including “click if visible”, “tap if visible”, “get text if visible”, and “type text if visible.” These actions can be applied specifically to execute only when the popups actually appear on the screen. You can find more details about each one of the actions in our official documentation.

So, you can create a step to the close the popup, and in the case the popup doesn’t appear during the adaptive wait threshold, the test will continue without failing. TestProject’s execution report will indicate a 100% pass rate, with an indication in the “If visible” action, stating that the element never appeared, causing the step not to execute, but pass regardless.

TestProject If Visible Action

In addition to the “if visible” actions, you can use our “Is visible” validations to validate if the element is visible or invisible on the page or screen and use the adaptive wait mechanism to determine if the step passes or fails. You can find all the available validations and more details in our official documentation.

TestProject Is Visible Action

Want to create an adaptive wait in TestProject?

Interested to give these new product capabilities a try? You can create a TestProject account for FREE. Once you have your account, you can jump in and start experimenting with the adaptive wait feature or check out our official documentation for more detailed information. If you run into any issues, please don’t hesitate to contact us, we are more than happy to help.

 

Kevin Dunne

About the author

Kevin Dunne

Kevin Dunne is the General Manager of TestProject, ensuring Tricentis’ commitment to innovation and delivering tools to create better software. With a deep interest in the emerging trends in software development and testing, Kevin is dedicated to collaborating with thought leaders in this space.

Kevin comes to Tricentis from Deloitte, where he managed testing on large government and Fortune 500 engagements delivering ERP implementations and custom software development. As one of the first employees at Tricentis, Kevin has seen many facets of the business working in sales, customer support, marketing, and product management.

Kevin holds a Bachelor of Science degree from Vanderbilt University.

Join TestProject Community

Get full access to the world's first cloud-based, open source friendly testing community. Enjoy TestProject's end-to-end test automation Platform, Forum, Blog and Docs - All for FREE.

Join Us Now  

Leave a Reply

FacebookLinkedInTwitterEmail