I would need an advice regarding an issue I am facing with testing an mobile application with Appium. My application is hybride, with native and Webviews parts.
Actually, I am doing executing a Test driven by a set of data that will vary from one iteration to the other (the data are live so I can’t afford to have a static set of data, just for your curiousity).
The process works.
The problem I am facing occurs when I want to repeat my test more than 10 times (this is an approximation).
Suddenly, starting a new iteration, Appium is no more able to locate my elements in my app.
Clearing the application data will fix the issue. If I suspend the execution, clear the application data and restart my iterations, the app will work fine.
Here is my question: for a performance purpose, I don’t want to put the appium:noReset capability to false, because I don’t want to restart all my execution from start each time (the application requires to set some preferences at the start up and I already have a test case for this). Would you have a recommendation how to evict the application data after N iterations?
Ideally, I would like to be able to do the same for Android and iOS. That would be the Grail.
From the description it seems that you hit a performance issue once you populate a certain amount of data. This may be a bug in the app, but more likely just normal behavior that only affects automation. You may be able to get around this issue by extending the implicit wait when you search for elements or by using an explicit wait in whatever language you are using. I would go with the latter.
You check this by doing some performance testing with Appium. 2 useful articles below:
Actually, I might not have said that the caching issue occurs with a WebView content.
In the following sequence, we try to find an image using XPath.
The following log was produced:
2024-09-11 13:19:27.302 DEBUG xx.xx.AppiumSession - AppiumSession current AppContext:::WEBVIEW
2024-09-11 13:19:37.653 WARN xx.xx.AppiumSession - Expected element was not found. For locator: //div[@id="banner"]/div[1]/img[@src='./images/ic_smiley.svg']
Here is a part of the code (using Groovy):
//...
try {
WebDriverWait wait = new WebDriverWait(driver, timeout)
return wait.until({d -> findElement(d as AppiumDriver, locator)})
} catch (Exception e) {
String message = "Expected element was not found. For locator: ${locator.searchValue}"
if (failOnMissing) {
LOGGER.logError(message)
throw e
} else {
LOGGER.logWarning(message)
}
}
//...
MobileElement findElement(AppiumDriver driver, Locator locator) {
if (locator.appContext != null) {
switchAppContext(locator.appContext)
}
switch(locator.searchStrategy) {
case SearchStrategy.XPATH:
return driver.findElementByXPath(locator.searchValue)
//...
}
}
To make my test work again, I need to clear the cache of the application (in my situation, I am using an Android Emulator)
And here are the stats before evicting the cache of the application
First point, yes, the application is mixing both context, native and webview.
The test we are writing is a kind of exploration test which moves between several screens. So we meet both context on the way.
For the second point, I need to check. I verified the elements were still reachable using AppiumInspector but I didn’t think about using the Chrome browser of the phone. I’ll keep you updated.
