Controlador de selenio para aplicaciones Winforms
Cualquier contribución es bienvenida :)
Este proyecto está utilizando
¿Por qué otro conductor, cuando ya hay https://github.com/microsoft/winappdriver? La aplicación que estoy probando es bastante grande con muchos elementos, y ese conductor se agotó después de 60 segundos en algunas consultas de XPath (ver este problema), y después de armar todo, la consulta terminó menos de 2 segundos.
Este proyecto se basa en la automatización de la interfaz de usuario de MS, que es parte de la API de accesibilidad de Windows.
La documentación oficial menciona el soporte para varias plataformas:
La automatización de UI se admite en los siguientes sistemas operativos: Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows 7, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 y Windows Server 2019.
No puedo confirmar que funcionará en esas plataformas, ya que solo tengo 10 empresas ganadas en mi máquina, pero todas las bibliotecas requeridas son parte del proyecto.
Hasta donde yo sé, no es necesario el modo de desarrollador.
Actualmente, no hay instalador. Clone el repositorio y cree el ejecutable a partir de las fuentes. Use el ejecutable encontrado en WinAppDriver.ServerbinDebugWinAppDriver.Server.exe
Se debe usar la última versión del controlador del cliente 3.141.0.0 al llamar al servidor.
Ok y Yes , se pueden agregar subtítulos adicionales estableciendo la capacidad de acceptAlertButtonCaptions con una lista de valores separada por semicolon Cancel y No , se pueden agregar subtítulos adicionales estableciendo la capacidad de dismissAlertButtonCaptions Comandos de selenio sin apoyo
Soporte de XPath:
//node[3] //node[@attribute = 'X'] Solo se implementa este comando Appium
Agregue una referencia a Selenium.WebDriver v3.141.0 (https://www.nuget.org/packages/selenium.webdriver/3.141.0) y está listo para ir.
El controlador puede iniciar el sistema en el proceso de prueba o adjuntar a un proceso en ejecución. Use capacidades para definir el proceso para adjuntar.
Cuando no se proporciona ningún argumento de línea de comandos, el servidor se iniciará en la dirección IP predeterminada http://127.0.0.1:4444 .
Se admiten las siguientes capacidades:
mode : start (valor predeterminado) o attachprocessId - ID del proceso para adjuntar aprocessName - Nombre del proceso para adjuntar aexePath o app : la ruta al ejecutable para iniciar el proceso (los argumentos no se pueden proporcionar en este momento)appWorkingDir : establezca el directorio de trabajo del nuevo procesomainWindowTitle : expresión regular para ayudar al winappdriver a reducir el proceso para unir asendKeyStrategy ( oneByOne | grouped | setValue ): estrategia para usar para escribir el texto en un campo de texto, el valor predeterminado es oneByOne , actualmente esta capacidad no se puede cambiar durante la sesión public static RemoteWebDriver CreateSessionByStartingTheApplication()
{
DesiredCapabilities desktopCapabilities = new DesiredCapabilities();
desktopCapabilities.SetCapability("app", "<name of the program to start>");
// or "exePath" desktopCapabilities.SetCapability("exePath", "<path to the executable to start the process>");
// following capabilities should be provided for UWP applications like Calculator or Clocks & Alarms
// optional - to set the working directory
desktopCapabilities.SetCapability("appWorkingDir", "<path to run the process in>");
// optional - to identify the process
desktopCapabilities.SetCapability("processName", "<name of the process>");
// optional - to identify the main window
desktopCapabilities.SetCapability("mainWindowTitle", "<name of the process>");
return new RemoteWebDriver(
new CommandExec(new Uri("http://127.0.0.1:4444"),
TimeSpan.FromSeconds(60)),
desktopCapabilities);
}
public static RemoteWebDriver CreateSessionByAttachingToRunningProcess()
{
DesiredCapabilities desktopCapabilities = new DesiredCapabilities();
desktopCapabilities.SetCapability("mode", "attach");
// attach to process using process name
desktopCapabilities.SetCapability("processName", "<name of the process to attach to>");
// with (optional)
desktopCapabilities.SetCapability("windowTitle", "<regular expression to narrow down the list of matching processes>");
// or attach to process using process id
desktopCapabilities.SetCapability("processId", "<id of the process to attach to>");
return new RemoteWebDriver(
new CommandExec(new Uri("http://127.0.0.1:4444"),
TimeSpan.FromSeconds(60)),
desktopCapabilities);
}
La ubicación del elemento recomendado está utilizando la expresión de XPath (aunque con un soporte de expresión limitado)
var webBrowser = session.FindElement(By.XPath("//Pane[@AutomationId='webBrowser']"));
Mecanismos de ubicación del elemento que son compatibles
TextBox#id Windows en la aplicación Win no es como Windows en el navegador. Las ventanas ( ControlType.Window ) se pueden anidar dentro del árbol de control, por ejemplo, en un elemento Tab .
La ventana se puede ubicar utilizando XPath Expression var window = session.FindElement(By.XPath("/Window/Pane/Window[@AutomationId='WindowName']")); o cambiando a ella session.SwitchTo().Window("WindowName"); , en el primer ejemplo, obtendrá la referencia del elemento, en el otro el contexto interno se cambia a una nueva ventana y elementos almacenados en caché durante las siguientes operaciones se pueden eliminar cuando la ventana está cañada session.Close() .
Tenga en cuenta que los envoltorios de elementos como OpenQA.Selenium.Support.UI.SelectElement no funcionan porque se esperan elementos select internacional y option .
Hay un truco bastante feo que evita la necesidad de cambiar de ventanas al buscar una ventana infantil usando la expresión XPath. De manera predeterminada, la búsqueda comienza en el elemento raíz de una ventana, la ventana principal o la ventana a la que se cambió el usuario, y la búsqueda de una ventana infantil estaba fallando ya que no era un niño directo de la raíz actual. La solución inicia la búsqueda de una ventana en el nivel superior.