Você parece estar no caminho certo para testes automatizados ao vivo, mas tem alguns fatores significativamente complicadores:
-
O conteúdo dinâmico aumenta a dificuldade de especificar um teste. Você geralmente tem que declarar em termos pelo menos um pouco mais genéricos.
-
Mas muito pior: Vários outros testes possivelmente concorrentes acontecendo em paralelo. Isso realmente aumenta a aposta. Se outros testes puderem adicionar "Alice" ou até "Bob" enquanto você estiver adicionando "Bob", não será possível presumir que os itens estarão em posições fixas no conjunto de dados ou que haverá uma contagem fixa deles. Suas condições de navegação e teste acabam tendo que ser muito mais flexíveis e genericamente declaradas. E você precisará ser flexível sobre falhas. Em um ambiente paralelo, alguns testes falharão invariavelmente, mesmo se forem especificados corretamente. Isso é inescapável. Se outra pessoa testar "excluir uma linha aleatória" ou "limpar todos os registros que começam com as letras A-F" enquanto estiver testando "adicionar uma linha de Bob", sua linha estará em risco. Com o tempo, com testes suficientes, algumas vezes o teste concorrente ganhará ocasionalmente. Será também ser uma falha transitória. Execute novamente o teste e é improvável que os testes colidirão novamente da mesma maneira. (Problemas transitórios podem fazer melhor as coisas, porque elas são mais raras, mas também piores. Eles são muito muito mais difícil de rastrear, entender e consertar, porque eles dependem do tempo.)
Algumas recomendações:
- Não desista de automação. Quanto mais complexos e dinâmicos forem os dados e o comportamento do aplicativo, mais importante é que os testes serão automatizados. Em sistemas complexos. você não terá a energia e o foco para testar repetidamente cada comportamento. Nem mesmo se você tem uma equipe grande fazendo o trabalho. A automação é o único caminho confiável a seguir. Seja paciente ao aprender a especificar esses testes de maneiras mais flexíveis e inclusivas.
-
Aumente o isolamento de seus testes. Atualmente, as instâncias em nuvem, as máquinas virtuais e os ambientes virtuais são incrivelmente baratos. Talvez você possa gerar sua própria instância do aplicativo para testar. Isso removeria completamente os bugaboos de paralelismo, simplificando seu trabalho. Ele também permite que você inicie com conjuntos de dados predefinidos e primitivos carregados para cada execução de teste ou sempre que for conveniente para suas necessidades de teste. No entanto, sei que isso pode ser difícil. Eu tenho estado em situações onde a gerência insistiu que não poderíamos pagar instâncias de teste separadas. Eu até trabalhei em produtos comerciais ao vivo, onde era obrigatório testar algumas coisas em sistemas de produção, com dados de produção ( arrepio ).
-
Aumente o isolamento de dados. Mesmo que você não consiga realizar seu próprio teste instância (s), você ainda pode aumentar o isolamento de seus testes. Eu geralmente uso dados obviamente únicos para fazer isso. Não adicione "Alice" e "Bob" por exemplo; adicione "Alice_21387" e "Bob_21387", em que o sufixo é um índice gerado aleatoriamente por execução de teste. Não é possível adicionar números a esses campos? Adicione letras aleatórias. Há muito pouca chance de que "Alicezcfh" e "Bobzcfh" sejam usados por qualquer teste concorrente.
-
Permita que seus testes falhem. A maioria das estruturas de teste tem a capacidade de esperar e repetir testes. Use-o. Deixe seus testes falharem até N vezes, com um segundo D atraso entre as corridas. Para muitos webapps, N = 3, D = 15 irá fazer o truque. Se não for uma opção incorporada ao seu test runner, é fácil escrever isso tipo de lógica de teste de nova tentativa.
-
Torne seus scripts de teste mais robustos no que eles esperam como resultados. Por exemplo, se após uma inserção o registro de "Bob" precisar estar em algum lugar de uma tabela, não escreva teste que espera que apareça exatamente na linha número 42. Escreva o teste para esperar "Bob" em algum lugar da tabela. (dica do chapéu para @Doc Brown )
Em resumo, não desista da abordagem automatizada. Existem maneiras de fazer isso funcionar. É imperfeito, especialmente se você estiver testando um sistema que está sendo alterado durante o teste. Às vezes você terá que refazer, endurecer e melhorar os testes à medida que avança. Mas pode ser prático e eficaz. É também sua única esperança real. A alternativa lógica, o teste manual repetido, nunca funcionará com nada que se assemelhe a facilidade, velocidade e confiabilidade.