Appium UI Tests waiting until something is completely loaded

[MAUIoxo]

Hey folks,

I am implementing UI Tests with Appium and UiAutomator2 ([email protected]) on Android side right now. I decided that I want to have Tests that take screenshots and compare them to reference screenshots.

I know, in general this is debatable. But, I don't know of a better way to compare everything in my UI including background images, locations, dimensions etc.. So, I decided to give that a try.

On Android, I sometimes have the problem, that ScrollBars of ScrollViews are not fade out when the screenshot is taken and are still visible. Or the Flyout is still not opened completedly or closed again when the View, to which the test should navigate, is loading and the screenshot is taken.

Basically, the general problem is, how long should I wait e.g. with Task.Delay(...).Wait(); or with a construct like the following, what should I really wait for in my UI when there are background images layouts that need time to be fully positioned etc.?

var wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10));
wait.Until(ExpectedConditions.ElementIsVisible(By.Id("elementId")));

Let's consider a View which should be displayed when I click something, what whould be an element I could wait for until it is present or in case of ScrollView with ScrollBars which are automatically fade out in 2-3 seconds on Android Emulator what should I wait here fore?

Any best practices I should follow so that there is no unnecessary waiting time and also no waiting time which is too short and the test fails when comparing the screenshot?

[DarkNoir]

How is your journey with Appium going? If both states of the scroll bars, visible or not visible, are valid you could check for either as passing. If one is not then you probably would not be asking, maybe ?. I am here looking for information to help me decide if I should try Appium. Scale 1 to 10, would you recommend?

[MAUIoxo]

Hi,
my experience with Appium is good so far and I would recommend using it.
There were some pitfalls and still are when identifying elements to see if they are loaded. But, in general, I can recommend such UI tests. I already could identify 3 bugs that I probably would not have recognized without. You really do not click the entire App everytime or when an Update comes. So, it is beneficial to have them.

Regarding the ScrollBar issue I was asking, I disabled all WindowAnimations now like this in my Appium TestBase for Android:

options.AddAdditionalAppiumOption("disableWindowAnimation", true);

You can also go one step further and provide an Argument to your App via Itent Arguments and analyze it in your Android MainActivity.cs like below and add it to your own AppExecutionState-Service so that you could disable things based on that in your App:

options.AddAdditionalAppiumOption(AndroidMobileCapabilityType.OptionalIntentArguments, "--ez isTestExecution true");

...
// Retrieve the "isTestExecution" parameter provided by Appium to determine if the application is in test execution mode
bool isTestExecution = Intent?.GetBooleanExtra("isTestExecution", false) ?? false;

// Obtain the AppExecutionState service and update its IsTestExecution property
var appExecutionState = ServiceHelper.GetService<AppExecutionState>();
if (appExecutionState != null)
{
    appExecutionState.IsTestExecution = isTestExecution;
}
...

All that is up to you, but in general I would say having such tests and not needing to click through your entire App to see if something is broken is beneficial. You don't necessarily need to compare screenshots to reference screenshots, but you could also just click Buttons or so in your Appium tests and compare things based on that.

[DarkNoir]

Awesome, thank you very much for the response! William Wallace Technology Leader William Wallace | LinkedIn<https://www.linkedin.com/in/wwallace> [cid:36bcc34c-963a-44d4-8c26-b065fb4e9401]

…

________________________________ From: MAUIoxo ***@***.***> Sent: Wednesday, March 5, 2025 10:59 PM To: dotnet/maui ***@***.***> Cc: William Wallace ***@***.***>; Comment ***@***.***> Subject: Re: [dotnet/maui] Appium UI Tests waiting until something is completely loaded (Discussion #26643) Hi, my experience with Appium is good so far and I would recommend using it. There were some pitfalls and still are when identifying elements to see if they are loaded. But, in general, I can recommend such UI tests. I already could identify 3 bugs that I probably would not have recognized without. You really do not click the entire App everytime or when an Update comes. So, it is beneficial to have them. Regarding the ScrollBar issue I was asking, I disabled all WindowAnimations now like this in my Appium TestBase for Android: options.AddAdditionalAppiumOption("disableWindowAnimation", true); You can also go one step further and provide an Argument to your App via Itent Arguments and analyze it in your Android MainActivity.cs like below and add it to your own AppExecutionState-Service so that you could disable things based on that in your App: options.AddAdditionalAppiumOption(AndroidMobileCapabilityType.OptionalIntentArguments, "--ez isTestExecution true"); ... // Retrieve the "isTestExecution" parameter provided by Appium to determine if the application is in test execution mode bool isTestExecution = Intent?.GetBooleanExtra("isTestExecution", false) ?? false; // Obtain the AppExecutionState service and update its IsTestExecution property var appExecutionState = ServiceHelper.GetService<AppExecutionState>(); if (appExecutionState != null) { appExecutionState.IsTestExecution = isTestExecution; } ... All that is up to you, but in general I would say having such tests and not needing to click through your entire App to see if something is broken is beneficial. You don't necessarily need to compare screenshots to reference screenshots, but you could also just click Buttons or so in your Appium tests and compare things based on that. — Reply to this email directly, view it on GitHub<#26643 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AF44DT7FIQMDI5DRTF2IUJT2S7W5BAVCNFSM6AAAAABTUPFT4KVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENBRGAZDGOA>. You are receiving this because you commented.Message ID: ***@***.***>