Quais recursos devem ser testados por meio de teste automatizado da interface do usuário?

Recentemente, um consultor nos informou que, se um recurso só pode ser testado por meio de testes automatizados de interface do usuário (por exemplo, Selenium, UI codificada), existe um problema de arquitetura subjacente. Embora essa declaração possa ser um pouco extremada, ela segue as mesmas linhas da pirâmide de testes, pois os testes de interface do usuário devem compor uma pequena parte do seu conjunto de testes automatizado geral.

Então, que tipos de recursos devem ter testes automatizados de interface do usuário? Um sistema com uma arquitetura convincente ainda terá recursos que só podem ser verificados por meio de testes de interface do usuário ou esses testes devem servir apenas como "backup" para um conjunto de testes de unidade e serviço?

Presumivelmente, você tem algum tipo de arquitetura que conecta botões e outros widgets às ações - clique em salvar e a função de salvar deve ser chamada etc.

Supondo que você tenha uma boa cobertura de teste das ações por meio de testes de unidade ou de integração, o objetivo do teste automatizado da interface do usuário é garantir que todos os widgets estejam fazendo chamadas apropriadas para as ações subjacentes e exibindo corretamente os resultados dessas ações.

Em outras palavras, eles validam que a interface do usuário reflete adequadamente o estado do modelo e está corretamente conectada ao controlador.

O outro componente é quando alguma lógica de negócios está no código da interface do usuário. Por exemplo, talvez você precise de certos caracteres em um campo de senha. Você precisa testar esses recursos de alguma forma, pois pode ser difícil ou impossível fazer isso por meio de testes de unidade.

Quais recursos devem ser testados por meio de teste automatizado da interface do usuário?

Todos os recursos da interface do usuário.

Você deve testar:

• Todas as funções que os usuários podem executar.
• Funções que os usuários executam em todos os navegadores (e versões) em que os executam.
• Ambos os caminhos felizes (fazendo a coisa certa a cada passo) e tristes (o usuário comete erros).
• Dados válidos e inválidos.
• Números grandes e pequenos.
• Todas as funções e funções específicas da função.
• Interfaces de usuário e administrador.
• Tentativas de invasão.
• A criação versus atualização de dados funciona conforme o esperado.
• Excluir o trabalho e excluir dados do banco de dados associado em outras tabelas.
• Usuários do estilo Teclado vs. Mouse.
• Diferentes dispositivos ou simuladores de - PCs, telefones, ipads etc.

Não existe um recurso que possa ser testado apenas através de testes de interface do usuário automatizados. Ferramentas como o selênio apenas imitam o comportamento de um ser humano, sem entediá-lo a ponto de se suicidar. Faça a si mesmo (ou ao seu consultor) uma pergunta: " Como um programa testaria aspectos da interface do usuário que uma pessoa não pode? " A próxima pergunta é: " Se sim, por que você se importaria com o que eles fazem? "

Por outro lado, se você tiver esse recurso, bem, sim, eu diria que você tem um problema de arquitetura subjacente. :-)