1

I use "WinAppDriver" on Windows 10 to automate button click using "Appium.WebDriver" NuGet package.

To find an element by it's "Id" or "Name", it takes more time (around 5 seconds initially) and the problem gets worse when WinAppDriver runs continuously for more than 30 minutes or 1 hour.

To avoid performance hit, instead of using "app", "root", I use "appTopLevelWindow", "topLevelWindowHandle" as shown below.

  1. Appium WindowsDriver object initialization:
    var topLevelWindowHandle = applicationWindow.GetAttribute("NativeWindowHandle");

    topLevelWindowHandle = int.Parse(topLevelWindowHandle).ToString("X"); 
    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.SetCapability("deviceName", "WindowsPC");
    capabilities.SetCapability("appTopLevelWindow", topLevelWindowHandle);
    windowsDriver = new WindowsDriver<WindowsElement>(new Uri("http://127.0.0.1:4723"), capabilities);
  1. Performing button click:
    if(windowsDriver != null)
    {
        testInformationDialog = windowsDriver.FindElementsByName("Test Information");

        ReadOnlyCollection<WindowsElement> okButton = null;
        //If test information dialog is present, get the ok button and click it
        if(testInformationDialog.Count != 0)
        {
            okButton = windowsDriver.FindElementsByAccessibilityId("210");
            if(okButton.Count != 0)
            {
                okButton.First().Click();
                Thread.Sleep(3000);
            }
        }
    }

Initially WinAppDriver takes around 5 secs to click the button. While continuously running and clicking the button for every ~5 secs, the time taken to detect the button gets increased. After around 1 hour, to find the same button, it takes 10 secs and the time taken keeps increasing linearly with running time of WinAppDriver. I want to get rid of this time delay. Please help.

popsiporkkanaa
  • 678
  • 1
  • 9
  • 17
Pradeep
  • 13
  • 1
  • 8
  • 1. Since Accessibility / Automation ID's should be unique, try using the variant without the "s": `FindElementByAccessibilityID`. You'll get a single `WindowsElement` instead of a `ReadOnlyCollection`. No need to iterate anything. 2. Try avoiding `Thread.Sleep()`, your 10 seconds contains 3 hard coded seconds. There are many resources explaining why you shouldn't use `Thread.Sleep()`. 3. See my answer [here](https://stackoverflow.com/questions/56971983/how-do-i-wait-for-an-element-using-the-winappdriver-in-uwp/56982846#56982846), about waiting for a element in a dynamic way with timeout. – PixelPlex Jul 17 '19 at 06:41
  • Thanks for your suggestion. 1. I used "FindElementsByAccessibilityID" instead of "FindElementByAccessibilityID" just to avoid InvalidOperationException if the element is not present. 2. As I run two applications in parallel, where one application should wait for other application for completing it's task, I used Thread.Sleep(). That's not part of my question. The issue is, when I run WinAppDriver for long time, it causes memory leak which can be seen clearly from Windows Task Manager. Please help me to prevent this. – Pradeep Jul 23 '19 at 06:03
  • A memory leak could be found anywhere in your project, it might be difficult for someone else to finding this leak for you. Visual studio has a tool for that though. Take a look [here](https://learn.microsoft.com/en-gb/visualstudio/profiling/memory-usage?view=vs-2019) if you haven't already. – PixelPlex Jul 23 '19 at 12:13
  • That's clear and I understand your point that it's not easy for someone to find memory leak in my application without analyzing complete code. Here for me, memory leak occurs only when I use WinAppDriver for UI automation. If no WinAppDriver used, then no memory leakage. What I mean by memory leakage is, the memory consumed (in Task Manager) by the application keeps growing during WinAppDriver UI automation. When I run the application manually, memory consumption is normal and it don't grow. The exact issue is raised here. https://github.com/Microsoft/WinAppDriver/issues/425. – Pradeep Aug 02 '19 at 02:55
  • Let me put it this way. It is the simplest way i can explain the issue. 1. Start windows calculator manually and keep clicking "+" button manually. You will not see any significant growth in memory consumption of calculator process in task manager. (Click only + button. Do not do any actual calculations. That would make memory to grow.) 2. Then do the same thing with WinAppDriver UI Automation. Open the calculator and click + button through winappdriver for 1000 times. You will see the increase of memory consumed by calculator process. – Pradeep Aug 02 '19 at 04:34
  • Ah OK, it wasn't clear to me the memory leak was in the program under test and that Winappdriver was causing this. Not a great solution (more like a hack) but the only thing I can think of at the moment is restarting the app under test through the script every X iterations or when the memory consumption gets to a certain value. – PixelPlex Aug 05 '19 at 06:48
  • For simple usecases such as automated UI testing, the workaround would work fine. But in my case the application under test is a calibration tool which expects the complete calibration to be executed before closing the app. During app closure, a calibration report will be generated. So this makes the workaround not suitable for my case. Please let me know if you find any solution. Thank you. – Pradeep Aug 13 '19 at 06:38
  • I read in the github link you provided that the leaked memory in the application under test gets released when winappdriver closes. If this is also the case for you, you could try and see if automatically closing the winappdriver session and starting a new one helps releasing that memory. Or perhaps make a command line script that closes winappdriver completely, restarts it and makes winappdriver continue where it stopped, e.g. by making the testscript recognise the current screen from the program under test? – PixelPlex Aug 13 '19 at 09:15
  • 2
    I finally scrapped WinApp Driver and switched to FlaUI which is basically a wrapper around Microsoft's native UI automation library. It works great for my case. – Pradeep Sep 23 '19 at 08:42

0 Answers0