Experiências com UI Automation e WPF [fechado]

Question

Estamos desenvolvendo um aplicativo baseado bastante grande WPF e gostaria de incluir alguns testes UI automatizado em nosso pacote de teste (que já contém uma série de testes de unidade).

O UI Automation Framework de Microsoft, em parte, soa como um ajuste perfeito para programaticamente lançar e interagir com o aplicativo em uma configuração de teste. No entanto, eu tenho lutado para encontrar referências sólidas para amostras e experiências com a tecnologia, os artigos e pequenas amostras disponíveis no MSDN não é o suficiente para me convencer de que é uma escolha sólida.

Então, alguém tem experiências do mundo real usando o framework de automação de interface do usuário em sua suíte de teste? Quais são as advertências e as armadilhas? Quaisquer melhores práticas quando os scripts de testes escritos, você pode "gravar e replay" para um formato programável, o quanto você deve facilitar os testes da aplicação, como você incorporá-lo na construção automática? Deveríamos estar olhando em outra direção que o Automation Framework UI?

Sinta-se livre para postar você experimenta aqui ou link para algumas boas referências que eu poderia ter perdido

Answer 1

Onde eu trabalho temos apenas começou a avaliar algumas ferramentas de teste para o nosso sistema. Nos deparamos com uma ferramenta chamada branca, que utiliza o Framework UI Automation. Nota que o branco também tem uma função de gravação, embora eu acho que tem aparência de problemas e ainda está sendo desenvolvido.

O que tentei fazer foi configurá-los para olhar como testes de unidade ou seja [TestFixture] [Test] etc. em seguida, fomos capazes de executá-los através nunit, ao mesmo tempo que os testes de unidade.

Nós descobrimos que ele pode ser difícil de acessar alguns dos componentes dentro de sua janela, mas não tive muita chance de investigar o porquê.

Se você não se importa de pagar para o software, então eu recomendo TestComplete .

Answer 2

Eu estou no meio de fazer a automação de interface do usuário de um aplicativo WPF no trabalho. Estou usando Branco e IronRuby e ele funciona muito bem. Eu escrevi como eu fiz isso aqui: http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby-and-white/

Answer 3

Inicialmente foi com branco, e em seguida, mudou-se longe dele. Ele tenta ser genérica e abstrata sobre o Win32 API, WinForms, aplicativos Java, e a automação API MS UI. O MS UI Automation API também está tentando ser genérica e abstrata sobre a api win32 e winforms e WPF, assim você acaba em um "menor denominador comum-de denominador comum mais baixo" cenário.

O resultado disso foi que o Branco elemento de busca API simplesmente não foi suficiente flexível para encontrar vários elementos de interface do usuário que precisávamos de encontrar, e não exponha o suficiente dos elementos estrutura de automação da interface do usuário subjacentes para nós para fazer qualquer coisa útil com ele.

Acabamos indo com um homegrown tipo-of-quadro; Usamos o quadro MS UIAutomation diretamente, mas têm métodos de extensão e classes auxiliares para lidar com os cenários não aborda. (Teclado e entrada de mouse, principalmente).

Nota: os nossos scripts de teste e quadro homegrown estão todos usando IronRuby. capacidade de Ruby para adicionar métodos para classes existentes e é sintaxe flexível (combinado com method_missing) são impressionantes para este tipo de coisa.