Driver de Selenium para aplicativos WinForms
Quaisquer contribuições são bem -vindas :)
Este projeto está usando
Por que outro motorista, quando já existe https://github.com/microsoft/winappdriver? O aplicativo que estou testando é bastante grande com muitos elementos, e esse motorista estava cronometrado após 60 segundos em algumas consultas XPath (veja esse problema) e, depois de juntar tudo, a consulta terminou em menos de 2 segundos.
Este projeto se baseia na automação da UI MS, que faz parte da API de acessibilidade do Windows.
A documentação oficial menciona suporte para várias plataformas:
A automação da interface do usuário é suportada nos seguintes sistemas operacionais: 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 e Windows Server 2019.
Não posso confirmar que funcionará nessas plataformas, pois só ganhei 10 empresas na minha máquina, mas todas as bibliotecas necessárias fazem parte do projeto.
Até onde eu sei, o modo desenvolvedor não é necessário.
Atualmente, não há instalador. Clone o repositório e construa o executável das fontes. Use o executável encontrado em WinAppDriver.ServerbinDebugWinAppDriver.Server.exe
O mais recente driver do cliente versão 3.141.0.0 deve ser usado ao ligar para o servidor.
Ok e Yes , legendas adicionais podem ser adicionadas definindo a capacidade de acceptAlertButtonCaptions com uma lista separada por vírgula Cancel e No , legendas adicionais podem ser adicionadas definindo a capacidade dismissAlertButtonCaptions com uma lista separada por vírgula Comandos de selênio não suportados
Suporte XPath:
//node[3] //node[@attribute = 'X'] Somente este comando Appium é implementado
Adicione uma referência ao Selenium.WebDriver v3.141.0 (https://www.nuget.org/packages/selenium.webdriver/3.141.0) e você está pronto para ir.
O driver pode iniciar o sistema em processo de teste ou anexar a um processo em execução. Use os recursos para definir o processo para anexar.
Quando nenhum argumento da linha de comando for fornecido, o servidor será iniciado no endereço IP padrão http://127.0.0.1:4444 .
Os seguintes recursos são suportados:
mode - start (valor padrão) ou attachprocessId - ID do processo a ser anexadoprocessName - nome do processo para anexarexePath ou app - caminho para o executável para iniciar o processo (os argumentos não podem ser fornecidos no momento)appWorkingDir - Defina o diretório de trabalho do novo processomainWindowTitle - Expressão regular para ajudar o WinAppdriver a diminuir o processo a se conectar asendKeyStrategy ( oneByOne | grouped | setValue ) - Estratégia a ser usada para digitar texto em um campo de texto, o valor padrão é oneByOne , atualmente esse recurso não pode ser alterado durante a sessão 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);
}
A localização recomendada do elemento está usando a expressão XPath (embora com um suporte de expressão limitado)
var webBrowser = session.FindElement(By.XPath("//Pane[@AutomationId='webBrowser']"));
Mecanismos de localização do elemento que são suportados
TextBox#id O Windows no aplicativo Win não é como o Windows no navegador. O Windows ( ControlType.Window ) pode ser aninhado dentro da árvore de controle, por exemplo, em um elemento Tab .
A janela pode ser localizada usando a expressão xpath var window = session.FindElement(By.XPath("/Window/Pane/Window[@AutomationId='WindowName']")); ou mudando para ele session.SwitchTo().Window("WindowName"); , no primeiro exemplo, você obterá a referência do elemento; no outro, o contexto interno é alterado para a nova janela e os elementos armazenados em cache durante as seguintes operações podem ser descartados quando a janela é cortada session.Close() .
Observe que os invólucros de elementos como OpenQA.Selenium.Support.UI.SelectElement não funcionam porque os elementos select e option são esperados internamente.
Há um hack bem feio que ignora a necessidade de trocar o Windows ao procurar uma janela infantil usando a expressão XPath. Por padrão, a pesquisa começa no elemento raiz de uma janela - a janela principal ou a janela para a qual o usuário mudou - e a busca por uma janela infantil estava falhando, pois não era um filho direto da raiz atual. A correção inicia a pesquisa por uma janela no nível superior.