Automação de testes WPF e testes de interface WinForms sem código (e sem árvore de acessibilidade)
Automação de testes WPF e testes de interface WinForms sem código: o que o seu aplicativo expõe a uma ferramenta de teste, o que esconde, e como gravar, verificar e executar um teste a cada build.
10 min de leituraPor Ait Nohaila, Representante de desenvolvimento de negócios
A resposta curta
Para automatizar testes de interface de um aplicativo WPF, grave um fluxo uma vez no GUI Test Studio: cada clique, cada tecla e cada asserção viram um teste que encontra cada controle pelas informações de acessibilidade do aplicativo, ou pela visão quando ele não diz nada.
Este guia é para um engenheiro de QA ou um desenvolvedor que tem um aplicativo WPF ou Windows Forms (WinForms) para testar.Ele mostra o que esse aplicativo informa a uma ferramenta de teste e o que esconde, grava um teste etapa por etapa, escolhe as asserções que sobrevivem a uma reformulação, executa o teste a cada build, e diz quando uma biblioteca baseada em código ainda é a melhor escolha.
O que um aplicativo WPF ou WinForms expõe a uma ferramenta de teste, e o que ele esconde
O WPF e o WinForms descrevem os controles padrão para o Windows pelo UI Automation: um tipo, um nome, um lugar na tela e, quando o desenvolvedor definiu um, um AutomationId.Um leitor de tela usa essa descrição, assim como toda ferramenta de teste que encontra controles por localizadores.O mesmo aplicativo também contém controles que não dizem absolutamente nada.
| Tipo de controle | O que o UI Automation vê | Como um teste o encontra |
|---|---|---|
| Um controle WPF padrão com AutomationId: Button, TextBox, ListView, DataGrid | O tipo, o nome, o lugar e o id que o desenvolvedor deu a ele | Pelo que o aplicativo diz, na hora |
| Um controle WinForms padrão: Button, TextBox, DataGridView | O tipo, o texto e o Name do controle como id, quando foi definido | Pelo que o aplicativo diz |
| Um aplicativo WinForms cujos controles mantiveram os nomes padrão | Tipos e textos, com ids como button1 que significam pouco | Pelo texto e pelo lugar do controle, e pela visão |
| Um controle que o próprio aplicativo pinta: um gráfico, um medidor, uma faixa de opções, um canvas | Um único retângulo, a menos que os desenvolvedores tenham escrito a acessibilidade dele | Pela visão |
| Uma grade ou lista desenhada pelo próprio aplicativo | Linhas sem as células, ou células com nomes genéricos | Pela visão, célula por célula |
| Uma suíte de controles de terceiros | Depende do fornecedor: de uma descrição completa a um único painel | Pelo que o aplicativo diz onde ele diz, pela visão onde não diz |
| Uma imagem, um ícone, um desenho | Uma imagem sem texto | Pela visão |
A própria documentação da Microsoft diz que um controle sem um provedor de UI Automation é em grande parte opaco para ele, que pouco consegue informar além da localização.Quais aplicativos do Windows não têm árvore de acessibilidade lista os tipos de aplicativo em que isso é a regra, e não a exceção.
Teste automatizado de um aplicativo WPF: grave-o etapa por etapa
O teste automatizado de um aplicativo WPF começa com uma gravação, no GUI Test Runner-Recorder.Nada é acrescentado ao aplicativo: nenhum build de teste, nenhuma biblioteca, nenhum AutomationId que você ainda não tivesse.O exemplo abaixo grava um aplicativo de entrada de pedidos, e um aplicativo WinForms é gravado do mesmo jeito.Veja Gravar um teste para todas as opções.
- 1
Clique em Gravar
Abra o GUI Test Runner-Recorder e clique em Gravar.Deixe o aplicativo no estado em que o teste deve começar: a primeira tela do fluxo, sem mais nada aberto nela.
- 2
Responda “O que você deseja testar?” com Um aplicativo
Escolha Um aplicativo e selecione o seu programa entre os que estão em execução, ou procure o .exe dele se ainda não estiver aberto.Marque a caixa que inicia o aplicativo com o teste e o fecha no final, para que cada execução comece com o aplicativo recém-aberto.
A tela inteira é sempre gravada.Escolher Um aplicativo só decide de onde vêm as asserções automáticas. - 3
Use o aplicativo como um testador faria
Digite o nome do cliente, escolha um produto na lista, clique em Salvar e leia a confirmação.Cada clique e cada tecla são gravados, e o gravador recorta uma imagem de cada controle em que você clica, logo antes do clique.Pressione a tecla Encerrar quando o fluxo terminar.
- 4
Responda “O que este teste deve verificar?”
Três cartões perguntam o que o teste deve verificar: os elementos visuais em que você clicou, o texto na tela, e o que apareceu enquanto você trabalhava, como uma caixa de diálogo ou uma confirmação.Mantenha os valores padrão para um primeiro teste, e salve.
As asserções são escolhidas depois da gravação, quando você acabou de ver o que o aplicativo fez. - 5
O teste é salvo em uma pasta própria, e é executado
Um teste chamado Orders é salvo como
Orders\Orders.GTS, em uma pasta própria, onde os resultados e o histórico de cada execução ficam guardados ao lado dele.Clique em Executar teste: o teste reproduz os seus cliques e teclas como entrada real, apontados para onde cada controle está agora, e termina em um Relatório de confiança que diz o que foi aprovado e o que mudou.
O que a gravação guardou sobre cada controle decide como ele é encontrado na próxima execução.
- Para o botão Salvar, o aplicativo disse Button, Salvar e SaveButton, e o teste guarda isso ao lado da imagem do botão.
- Para o gráfico, o aplicativo não disse nada que valesse a pena guardar, e só a imagem o encontra.
Você também pode pular a gravação e descrever o fluxo em um prompt para o Claude, o ChatGPT ou um modelo de IA local, um que fornecemos ou um que você traz: o teste é criado do mesmo jeito, com as mesmas asserções.
Testes de interface no WinForms: as asserções que sobrevivem a uma reformulação
Os testes de interface no WinForms, como os testes no WPF, dependem de asserções que detectam uma mudança real e ignoram as inofensivas.O GUI Test Studio oferece três tipos, cada um sendo um bloco na linha do tempo do teste que qualquer pessoa da equipe pode adicionar, mover ou editar.
Asserção visual
Uma asserção visual verifica se um elemento está na tela e tem a aparência gravada: um ícone da barra de ferramentas, uma luz de status, um gráfico que deve mostrar a mesma curva.
Asserção textual
Uma asserção textual verifica as palavras que um elemento mostra, perguntando primeiro ao aplicativo e lendo a tela quando o aplicativo não consegue dizer, e uma asserção textual dinâmica aceita um valor que muda pelo formato, como um número de pedido.
Asserção de layout
Uma asserção de layout verifica se os elementos de uma tela estão dispostos como foram gravados, então uma coluna que se moveu ou um botão que perdeu o lugar é detectado mesmo quando cada elemento ainda parece certo.
As três ignoram o ruído que toda tela tem e ainda assim detectam o que uma pessoa chamaria de mudança: uma cor errada, um ícone ausente, uma palavra que mudou de maiúscula para minúscula, um controle que saiu do lugar.Asserções visuais explica as configurações de cada uma.
A área de busca
Cada asserção busca o seu elemento dentro de uma área de busca, uma área em torno de onde o elemento foi gravado.A área separa os elementos parecidos: um botão Salvar na barra de ferramentas e um botão Salvar em uma caixa de diálogo são diferenciados pelo lugar onde cada um está.Uma asserção que não encontrou o seu elemento na área depois de um segundo também busca na tela inteira, então uma janela que abriu mais à direita não reprova o teste, e o Relatório de confiança diz onde o elemento foi encontrado.
Uma reformulação do código por trás de um controle
Um teste continua funcionando ao longo das mudanças pelas quais um aplicativo WPF ou WinForms passa.
- Um controle reescrito de WinForms para WPF continua sendo encontrado: o aplicativo ainda o nomeia, e ele ainda tem a mesma aparência.
- Um controle movido para outro painel é encontrado onde está agora.
- Uma classe renomeada ou uma nova biblioteca de controles não muda nada daquilo em que o teste se apoia.
Um tema escuro, um tema de alto contraste, outro idioma
As informações de acessibilidade do aplicativo não mudam com um tema, então uma asserção que pergunta ao aplicativo vale tanto no tema claro quanto no escuro.A imagem que uma asserção visual compara muda, sim, e um perfil de linha de base guarda uma versão esperada por ambiente: execute o teste com o perfil Modo escuro, aceite cada nova aparência uma vez no Relatório de confiança, e o mesmo teste passa a verificar a aparência clara e a aparência escura, cada uma em relação à versão certa.
Um localizador quebra quando o código muda.Uma asserção que pergunta ao aplicativo e olha para a tela quebra quando a tela está errada, que é a única falha que você quer.
Automação de testes de desktop do Windows a cada build
A automação de testes de desktop do Windows compensa quando é executada sem que ninguém precise iniciá-la.O gtr-cli, o executor de linha de comando, executa um teste exatamente como o botão Executar teste e responde como um pipeline espera: um teste que falha faz o build falhar, um arquivo JUnit preenche a aba de testes, e cada imagem do que falhou fica guardada em uma única pasta.
gtr-cli run tests --countdown 0 --junit results\junit.xml --artifacts results\artifactsUma opção indica a ferramenta de CI, e as falhas passam a aparecer no próprio log dela, como anotações ou entradas de teste, sem nenhum plugin para instalar:
| Ferramenta de CI | O comando | O que a ferramenta mostra |
|---|---|---|
| TeamCity | gtr-cli run tests --countdown 0 --format teamcity --artifacts results\artifacts | Cada teste na aba de testes, as falhas com os motivos |
| Azure DevOps | gtr-cli run tests --countdown 0 --format azure --junit results\junit.xml --artifacts results\artifacts | Um comando de log por falha, e o arquivo JUnit na aba de testes |
| GitHub Actions | gtr-cli run tests --countdown 0 --format github --junit results\junit.xml --artifacts results\artifacts | Uma anotação por falha na execução, e a pasta de artefatos para baixar |
Um teste de desktop é reproduzido em uma tela real, então o agente de build precisa de uma sessão de área de trabalho do Windows desbloqueada: uma máquina virtual com um tamanho de tela fixo funciona bem.Executar testes no seu pipeline lista todas as opções, e Execute os seus testes de ponta a ponta a cada build configura um build do TeamCity etapa por etapa, com o mesmo comando para o Jenkins, o GitHub Actions, o GitLab e o Azure DevOps.
FlaUI, pywinauto e outras ferramentas de teste de interface WPF: quando o código é a escolha certa
Duas bibliotecas de código aberto são o que um desenvolvedor usaria no lugar.O FlaUI é uma biblioteca .NET para testes automatizados de interface de aplicativos Windows, entre eles WPF e WinForms, que encapsula as bibliotecas de UI Automation da Microsoft para um teste escrito em C#.O pywinauto, segundo a página dele no GitHub, é um conjunto de módulos Python para automatizar a interface gráfica do Windows, com dois back-ends: a API Win32, a opção padrão, e o UI Automation.
Os dois são uma escolha justa para uma equipe que trabalha com código e cujos controles são todos acessíveis: os testes ficam no próprio repositório do aplicativo, em uma linguagem que a equipe escreve todos os dias, ao lado dos testes unitários, e um desenvolvedor que conhece a árvore de controles pode escrever um localizador preciso para cada elemento.O custo é pago em tempo de desenvolvedor, para cada localizador e para cada reformulação que muda um deles, e um elemento que o aplicativo não descreve precisa de outro caminho.
As duas abordagens não são inimigas.Uma equipe com um aplicativo WPF cheio de controles personalizados muitas vezes mantém os testes unitários em código e grava os testes de ponta a ponta, para que as pessoas que melhor conhecem os fluxos possam mantê-los, e os controles que o aplicativo não descreve também são testados.
Pontos principais
- 1O WPF e o WinForms descrevem os controles padrão, e não dizem nada sobre um gráfico, um medidor, uma grade desenhada pelo próprio aplicativo ou muitos controles de terceiros.
- 2Uma única gravação testa os dois tipos: o GTS Engine + AI pergunta primeiro ao aplicativo e encontra o controle pela visão quando o aplicativo não diz nada.
- 3Escolha asserções que sobrevivem a uma reformulação: uma asserção visual, uma asserção textual e uma asserção de layout só reprovam quando a tela está errada, e um perfil de linha de base cobre um tema escuro.
- 4Execute-o a cada build com o gtr-cli, no TeamCity, no Azure DevOps, no GitHub Actions, no Jenkins ou no GitLab, em uma área de trabalho do Windows desbloqueada.
- 5O FlaUI e o pywinauto ainda fazem sentido para uma equipe que trabalha com código e cujos controles são todos acessíveis; o custo é o tempo de desenvolvedor para cada localizador.
Perguntas
Como automatizar testes de interface de um aplicativo WPF?
Grave um fluxo uma vez no GUI Test Studio: abra o aplicativo, clique, digite e leia o que aparece, como um testador faria.Cada ação e cada asserção viram um teste sem código, e o gtr-cli o executa de novo a cada build.Cada controle é encontrado pelas informações de acessibilidade do aplicativo, ou pela visão quando o aplicativo não diz nada sobre ele.
É possível testar um aplicativo WinForms que não tem AutomationIds?
Sim.Um controle WinForms padrão ainda informa o tipo e o texto, e um controle que não informa nada útil é encontrado pela visão, pela imagem dele na tela.Nada precisa ser acrescentado ao aplicativo para o teste funcionar.
Preciso acrescentar AutomationIds ao meu aplicativo WPF para a automação de testes?
Não com o GUI Test Studio.Um AutomationId ajuda, porque assim o aplicativo nomeia o controle com precisão, e o GUI Test Studio o guarda quando existe.Sem ele, o nome, o tipo e o lugar do controle, e a imagem dele, bastam.
Como testar controles desenhados sob medida ou de terceiros em um aplicativo WPF?
Pela visão.Um gráfico, um medidor, uma grade desenhada pelo próprio aplicativo ou um controle de terceiros muitas vezes mostra ao Windows um único retângulo vazio.O GUI Test Studio encontra esse controle pela imagem na área de busca, age sobre ele com entrada real de mouse e teclado, e verifica o que ele mostra da mesma forma.
Qual é uma alternativa ao FlaUI que não exige código?
O GUI Test Studio.O FlaUI é uma biblioteca .NET que conduz o UI Automation do Windows a partir de código C#, então cada elemento precisa de um localizador em um projeto de teste.O GUI Test Studio grava o fluxo em vez disso, guarda sozinho as informações de acessibilidade do aplicativo, e encontra pela visão o que o aplicativo não descreve.
A automação de testes WPF funciona com um tema escuro?
Sim.As informações de acessibilidade do aplicativo não mudam com um tema, e para as asserções que comparam uma imagem, um perfil de linha de base guarda uma versão esperada por tema.O mesmo teste é executado na aparência clara e na aparência escura, e compara cada uma com a versão certa.
Os testes de WPF e WinForms podem ser executados em um pipeline de CI/CD?
Sim.O gtr-cli executa os testes em um agente de build Windows com uma sessão de área de trabalho desbloqueada, faz o build falhar quando um teste falha, gera um arquivo JUnit e guarda todas as imagens de uma falha.Ele funciona com o TeamCity, o Azure DevOps, o GitHub Actions, o Jenkins e o GitLab.
É preciso instalar alguma coisa dentro do aplicativo?
Não.O GUI Test Studio observa a tela, pergunta ao Windows o que o aplicativo já descreve sobre si mesmo, e usa o mouse e o teclado como uma pessoa.Não há biblioteca, nem build de teste, nem agente dentro do aplicativo.
Microsoft, Windows, WPF, Windows Forms, FlaUI, pywinauto, TeamCity, Azure DevOps, GitHub, GitLab e Jenkins são marcas comerciais ou projetos dos respectivos proprietários.
Pronto para gravar o seu primeiro teste?
Todos os recursos, por 15 dias.
Prefere ver no tipo de aplicativo que você testa?Agende uma chamada gratuita de 30 minutos com a nossa equipe.