One of the biggest challenges in Test Automation is to handle test flakiness due to the dynamic wait issues. But as technology evolve there comes a way to handle those issues in a smarter way, Adaptive Wait Capability by TestProject is a result of that.
This flakiness happens since we are not able to predict at which point page elements become interactable, even after the loading of the application. Even minor factors such as internet speed, resource loading, etc can impact your tests and lead them to failure. And eventually will end up with errors such as NoSuchElementException, StaleElementException, ElementNotVisibleException etc.
As a workaround to handle these situations, we were using Wait Techniques:
- Thread.sleep(): It sleeps the thread. Usually, it helps to get the job done, but significantly impacts the performance of scripts and produces inconsistent results sometimes. So it’s not advisable to use it.
- Implicit Wait: Configures the driver with a specific timeout to find an element. This also will be used throughout the test scripts which might impact our test script performance.
- Explicit Wait: It configures the driver to wait until a specific expected condition is met such as element visible, element present, etc. Here, we’ll be creating a new instance of the wait object passing our driver instance and specify the timeout. Out of all other approaches, this is the most advisable one.
- Fluent Wait: It configures the driver to wait for a condition along with the frequency with which we want to check the condition before throwing an exception.
These solutions will lead us to certain pain points such as:
- Unstable execution output
- Slower execution time
- Difficult to debug and identify root causes
- Maintenance issues
- Performance issues
Some other options which I come across were:
- I have also read about other libraries which helps to handle the unpredictable wait issues for web applications: Awaitility library, WebDriverWait.until() which allows flexibility to customize wait conditions directly from WebDriverwait Object with the help of lambda expressions(Link to the discussion thread)
- Also, Katalon Studio provides an option for Smart Wait to handle Web loading Issues (Which is available in the latest version). It introduces automatic wait for all front-end processes of web page to complete before moving to the next step. It can be enabled for whole project from settings.
Now, let’s see what TestProject’s Adaptive wait Capability offers us:
Adaptive wait intelligently waits for actions and validations before proceeding with the test which helps us to handle async waits in a smarter way for Selenium or Appium scripts.
The first thing which attracted me when they launched this is the capability of this feature to handle dynamic wait issues for web and mobile(iOS & Android) applications whereas Katalon Smart Wait supports only for Web application tests.
Also, TestProject offers explicit waits, which are available for each step. We can add an explicit wait time either before or after the execution of a specific test step.
Then as a bonus, there comes two advanced capability(If visible & Is Visible) to handle unexpected test failures due to random popups and to perform validations respectively.
It’s difficult to handle dynamic popups since we can’t create a common step to close the popup always. So, with the help of If visible capability the step to close popup will wait until the adaptive wait threshold, and if it’s not appeared the test will continue without fail & provides information about the steps in TestProject execution report.
Is visible provides us the capability to validate if the element is visible or not on the page and uses the adaptive wait to determine the step status.
Please refer to the documentation on Adaptive Wait Capability from here:
TestProject Adaptive Wait Capability
My Personal Experience with Adaptive Wait:
In our application, we have search functionality that displays results when the user enters search keyword. Due to network issues there were delay in displaying the results sometimes and our scripts were failing during continuous nightly execution. We tried several workarounds to fix it in our existing framework but it ended up in long delays for execution. Also, there was a scenario in which a popup was triggered randomly, we were handling it with several lines of code to verify and then continue along with a long delay.
So, when TestProject announced the new adaptive wait capability, I decided to try it out for the scenarios which we had delay issues. I have added the default threshold with a particular condition and executed the tests for several times to ensure stability. So far the test results are reliable and it works with ease as the capability adapts to the actual application loading pace and executes the next action only once the proper conditions are met. I have also tried this with some sample test websites which are also working flawlessly.
I would like to recommend this feature if dynamic(async) waits seems to be a never-ending issue for your automation scripts.
And it comes with the following advantages:
- Same capability works for both Web and Mobile
- Easy setup and configuration for SDK tests and recorded tests
- Removes the unnecessary wait time during execution
- And this capability comes with TestProject’s free platform
Be Smart by adapting the advanced Adaptive wait capability… 🙂
Leave a Reply