Esperando el elemento antes de hacer clic con WinAppDriver

Tengo un problema tan trivial, pero estoy teniendo dificultades para hacer que mi código espere correctamente un objeto antes de continuar.

Tengo la siguiente configuración establecida para mi controlador

session.Manage().Timeouts().ImplicitWait = TimeSpan.FromSeconds(60);

Esperaba que esto significara que esperaría un mínimo de 60 segundos antes de arrojar errores relacionados con la identificación del elemento, como

Message: System.InvalidOperationException : An element could not be located on the page using the given search parameters.

Sin embargo, éste no es el caso. Recibo el error alrededor de 2 segundos cuando intento llamar al siguiente comando.

WindowsElement btn = session.FindElementByXPath("//Button[@Name='NEXT']");
btn.Click();

El error aparece en la línea donde solo estoy definiendo las propiedades de los botones y no en el método Click () real. ¿No estoy pasando las propiedades de los elementos correctamente? ¿Por qué la instanciación del botón también haría la búsqueda?

Hay un problema abierto en el github de winappdriver. Eche un vistazo a este comentario al respecto. Parece ser un problema de Appium. No tengo idea del estado de este problema.

Básicamente, esto significa que tendrá que recurrir a una solución alternativa. Usar Thread.Sleep(/*milliseconds*/)es una mala idea .

Implementé un whilebucle en una función para obtener un control por ID de automatización como este:

    /// <summary>
    /// Gets a UI element based on a AutomationId.
    /// </summary>
    /// <param name="automationId">The AutomationId is a unique value that can be found with UI inspector tools.</param>
    /// <param name="controlName">The name of the UI element.</param>
    /// <param name="timeOut">TimeOut in milliseconds</param>
    /// <returns></returns>
    protected WindowsElement GetElement(string automationId, string controlName, int timeOut = 10000)
    {
        bool iterate = true;
        WindowsElement control = null;
        _elementTimeOut = TimeSpan.FromMilliseconds(timeOut);
        timer.Start();

        while (timer.Elapsed <= _elementTimeOut && iterate == true)
        {
            try
            {
                control = Driver.FindElementByAccessibilityId(automationId);
                iterate = false;
            }
            catch (WebDriverException ex)
            {
                LogSearchError(ex, automationId, controlName);
            }
        }

        timer.Stop();
        Assert.IsFalse(timer.Elapsed > _elementTimeOut, "Timeout Elapsed, element not found.");
        timer.Reset();

        return control;
    }

Usar un bucle tiene algunas ventajas versus Thread.Sleep(), es más flexible y tiene muchas más opciones que simplemente bloquear la ejecución del código.

Algunas de las ventajas:

• Su secuencia de comandos de prueba sigue ejecutándose: Imagine que su secuencia de comandos se detiene durante 5 segundos mientras la aplicación bajo prueba continúa. Pueden pasar muchas cosas en esos 5 segundos de los que su guión querrá saber. Pero no puede, porque la ejecución del código está bloqueada si usa 'Thread.Sleep ()'.
• Espera dinámica: un ciclo while se repetirá hasta que se cumpla la condición. Esto hace que su script continúe con la prueba tan pronto como se cumpla esta condición, haciendo que su script se ejecute más rápido. Por ejemplo, está esperando que se cargue una página. Thread.Sleep(5000)se asumirá que está bien para continuar, mientras que el bucle sabe que está bien para continuar con la prueba.
• Con la combinación de temporizador / tiempo de espera, puede verificar cuánto tiempo tomó la operación (por ejemplo, guardar algunas ediciones) y si tomó más tiempo que el tiempo de espera, sabe que no está bien continuar.

Alternativamente, este código funcionará igual de bien:

protected WindowsElement GetElement(string automationId, string propertyName, int timeOut = 10000)
{
    WindowsElement element = null;
    var wait = new DefaultWait<WindowsDriver<WindowsElement>>(Driver)
    {
        Timeout = TimeSpan.FromMilliseconds(timeOut),
        Message = $"Element with automationId \"{automationId}\" not found."
    };

    wait.IgnoreExceptionTypes(typeof(WebDriverException));

    try
    {
        wait.Until(Driver =>
        {
            element = Driver.FindElementByAccessibilityId(automationId);

            return element != null;
        });
    }
    catch(WebDriverTimeoutException ex)
    {
        LogSearchError(ex, automationId, propertyName);
        Assert.Fail(ex.Message);
    }

    return element;
}

El código anterior solo arrojará un en WebDriverTimeoutExceptionlugar de lanzar continuamente NoSuchElementException. No usa un bucle while, pero sospecho que wait.Until(...)está haciendo algo similar, ya que WinAppDriver sondea la interfaz gráfica de usuario cada 500 ms (consulte la PollingIntervalpropiedad en el DefaultWaitobjeto.

Espero que esto ayude:

public void WaitTillControlToDisplay(WindowsElement control , int Waittime=30)
{
    int startTime = 0;

    while (startTime < Waittime)
    {
        try
        {
            if (!control.Displayed)
                startTime += 1;
            else
            {
                Thread.Sleep(1000);
                return;
            }
        }
        catch (OpenQA.Selenium.WebDriverException)
        {
            Thread.Sleep(1000);
            return; // We should have Control loaded by now
        }

         Thread.Sleep(1000);
    }

    Assert.Fail("Time Out : Control - "+control+" Did not loaded within "+Waittime+" Seconds");

}

Aquí controlconviene identificarlo antes de pasarlo al método. A veces, los controles estarán dentro de otro contenedor, por lo que es mejor identificarlo y pasarlo al método.