Como você pode escrever testes para o selênio (ou similar) que não falham devido a alterações menores ou estéticas?

Passei a última semana aprendendo selênio e construindo uma série de testes na web para um site que estamos prestes a lançar. foi ótimo aprender, e eu aprendi algumas técnicas de localização xpath e css.

o problema para mim, no entanto, é ver pequenas alterações interromper os testes - qualquer alteração em uma div, um ID ou algum número de autóide que ajude a identificar widgets interrompe qualquer número de testes - apenas parece ser muito frágil.

então você escreveu testes de selênio (ou outros similares) e como você lida com a natureza frágil dos testes (ou como você os impede de serem quebradiços) e para que tipo de testes você usa o selênio?

testing selenium

— Sam J
fonte

Se pequenas alterações estão interrompendo os testes, eles não serão executados após as alterações - que é o objetivo dos testes. Além disso, a conscientização do desenvolvedor sobre os (existência dos) testes parece estar faltando.

— talonx

@talonx - não basta apenas executar esse tipo de teste, se uma pequena alteração resultar em uma grande alteração na suíte, será problemático, independentemente de serem executados pelo desenvolvedor, pela caixa ci ou pelos testadores

— FinnNk

@FinnNK: Concordo - pequenas mudanças não devem resultar em grandes mudanças. Isso significa que os casos de teste foram escritos por alguém que não está em contato com os desenvolvedores que estão fazendo as alterações - cheira a uma lacuna na comunicação.

— talonx

@talonx: os testes de interface do usuário são inerentemente frágeis e levam muito mais tempo para serem executados do que os testes de unidade. Eles são um desafio especial, então eu não tiraria conclusões precipitadas sobre os desenvolvedores na organização do @ Sam.

— azheglov

Eu mudei o título - espero que seja um pouco mais representativo da pergunta e um pouco menos negativo.

— Jon Hopkins

Respostas:

O objetivo do Selenium é criar testes de integração orientados à interface do usuário .

Os testes de integração verificam se todos os componentes do seu sistema funcionam corretamente quando implantados juntos. Testes de integração não são uma estratégia de teste suficiente e complementar outras estratégias de teste com uma abordagem diferente, como por exemplo unidade de testes e de testes de aceitação .

Os testes orientados à interface do usuário são inerentemente frágeis, embora Selenium e Watir estejam a um passo dos primeiros dias das ferramentas de gravação e reprodução . Existem várias maneiras de lidar com esse problema - aqui está uma compilação de conselhos de alguns especialistas de classe mundial:

Não tente obter toda a sua cobertura de teste desse tipo de teste . Robert C. Martin argumenta que sua cobertura de código pelos testes de integração deve ser de aproximadamente 20% . É simplesmente impraticável testar todos os caminhos de execução quando a entrada está a várias camadas do aplicativo.

Obtenha a maior parte da cobertura dos testes de unidade e de aceitação . Procure links para os artigos de Gojko Adzic na resposta de FinnNk . Adzic discutiu várias vezes sobre o teste da lógica de negócios por meio de testes de aceitação e ignorar a interface do usuário.

Mas ainda é necessário escrever uma quantidade de testes orientados à interface do usuário . É aqui que você precisa de alguns conselhos práticos, além de "não teste sua lógica de negócios via interface do usuário". Eu recomendaria o blog de Patrick Wilson-Galês como ponto de partida.

— azheglov
fonte

O link para patrickwilsonwelsh.com não está mais funcionando, e outro recurso para isso .. !!

— Marmik

A coisa mais importante ao criar testes como esse, depois que você passa por um número trivial, é a ideia de mudança simétrica - uma pequena alteração no código deve resultar em uma pequena alteração no conjunto de testes.

Por exemplo, digamos que você colete o nome de alguém com duas caixas de texto em 100 testes. Se você escrever esses testes com facilidade (ou talvez esteja usando a reprodução de registros), terá 100 testes para alterar. Se, em vez disso, você abstrair uma etapa de "inserir nome" e usá-la em seus testes, em vez de usar diretamente selênio, você terá apenas um lugar para fazer sua alteração. Vai depender do seu contexto quantas camadas de abstração você usar - mas o uso da abstração ajudará bastante a tornar seus testes sustentáveis.

Uma segunda coisa importante é garantir que seus seletores sejam baseados na coisa mais importante e com menor probabilidade de alteração. Às vezes, isso será um ID ou uma classe ou poderá ser o texto ou um elemento ao redor. Sempre prefira o seletor mais simples (por exemplo, um ID), mas às vezes para conseguir isso, você terá que usar algo como xpath.

Gojko Adzic tem muitos bons conselhos em seu blog quando se trata desse tipo de teste - confira seu Sine of Death e como evitá-lo em particular.

— FinnNk
fonte

boas dicas FinnNk - eu abstraí métodos comuns (faça login, procure por widgets da barra lateral etc.) - para que o dano seja reduzido quando os testes mudam. Infelizmente, estamos usando um sistema de propriedade que cria alguns dos widgets e cria IDs para widgets com base em sua posição no dom; portanto, sempre que algo é movido, os testes são interrompidos.

— Sam J

Geralmente, você pode encontrar uma maneira de identificar um elemento - talvez algum texto que esse elemento contenha, ou talvez ele sempre tenha a mesma posição relativa a outra coisa. Finalmente, como último recurso, você também pode definir estratégias localizadas personalizadas para localizar elementos usando o selênio, o que lhe dá controle total (por exemplo, se você estiver procurando por elementos com o nome nome da base e algumas coisas arbitrárias adicionadas ao final, como no seu caso ou em formulários da web asp.net).

— FinnNk

O teste garante que o código se comporte conforme o esperado. Se seus testes são interrompidos regularmente, eles não estão testando a coisa certa ou os desenvolvedores não se importam com os testes.

Pessoalmente, acho que, se a presença de uma <div>etiqueta interromper um teste, ele será desnecessariamente estritamente dependente das tags circundantes, e uma abordagem mais branda deve ser adotada.