Estratégias de execução de teste de aceitação para aplicativos pesados de configuração inicial

5

Temos um sistema com cerca de 250 tabelas. A configuração inicial inclui a execução de cerca de 50 consultas (conhecidas também como sementes).

Estamos tentando estratégias para automatizar nossos testes de aceitação, e nossa primeira escolha foi limpar e reconstruir o banco de dados em todos os cenários (ou seja, todos os testes), para que pudéssemos mantê-los isolados do resto: significando " listar todos os recursos "cenário não verificaria um recurso criado em um cenário" criar "anteriormente executado.

Não tenho certeza se esse "isolamento" trará algum benefício mensurável, mas isso aumenta o tempo de execução de cada cenário (cerca de 20 segundos em cada cenário).

É considerada uma prática ruim, ou trará qualquer problema de escalabilidade conhecido, se mudarmos nossa estratégia para fazer isso configuração inicial somente no começo da configuração fase da execução dos testes (ou talvez no início de cada suíte de testes) e não em todos os cenários?

Se isso ajudar, estamos testando usando o Behat (a versão oficial do PHP do Cucumber ).

    
por Christopher Francisco 13.11.2016 / 23:44
fonte

1 resposta

2

Isso não é de forma alguma uma prática ruim. Pode parecer um exagero, mas fazendo integração / tipo de sistema de teste de tal forma dá-lhe enormes benefícios.

Os testes tornam-se muito menos frágeis quando você os configura dessa maneira. Imagine que você adicione um novo teste apenas para descobrir que todos os outros testes executados posteriormente falharão. Isso costuma acontecer porque os outros testes dependiam de um estado anterior que você alterou agora. O que você faz agora?

  1. Você pode alterar a maneira de escrever seu novo teste para que ele não altere o estado dos testes subsequentes
  2. Você atualiza todos os outros testes por trás do novo

Ambas as opções são bastante terríveis. A opção nº 1 restringe demais, então, em vez de escrever um teste que realmente verifica o caso de uso completamente, você escreve um teste no qual testa apenas um recurso. Opção # 2 vai demorar uma eternidade e deixa você com um gosto muito amargo em sua boca.

Se você aplicar a estratégia em que os testes não dependem do estado anterior, você só precisa executar esse único teste sabendo que, com uma probabilidade muito alta de que ele funcionará bem como parte de todo o conjunto. Portanto, leva-se um muito menos tempo desde o desenvolvimento até integração completa . A capacidade de executar um único teste por si só torna muito mais fácil isolar e depurar problemas . O contexto que um desenvolvedor precisa manter em seu cérebro também é minimizado, tornando mais fácil se concentrar na tarefa em questão. Resumindo, levará muito menos tempo e também será muito mais divertido desenvolver e manter esses testes.

Como você mencionou um ponto negativo ao configurar o estado antes de cada teste, a execução geral do conjunto leva mais tempo. Eu concordo que isso é irritante e você tem que considerar com que frequência esses testes precisam ser executados. No tipo de teste de aceitação das minhas equipes, só corríamos no máximo uma vez por dia, mas não em cada check-in e eles tinham suas próprias builds dedicadas (em outras palavras, elas eram NÃO parte da integração contínua ).

Uma maneira de acelerar o tempo de execução dos testes é limitar a quantidade de propagação para testes individuais. Considere somente a criação do mínimo absoluto que o caso de teste específico requer para ser executado.

Você também precisa facilitar e fazer a semeadura inicial. A manutenção dos scripts iniciais é uma parte importante da manutenção dos próprios testes . Você precisa ser capaz de compartilhar facilmente as entranhas da semeadura entre testes (pense em métodos / classes de semente que você reutiliza na configuração) o que torna mais fácil para todos semear e também torná-los centralizados, então se algo mudar fundamentalmente, você só precisa atualizar em um só lugar.

Espero que isso ajude. Boa sorte e teste!

    
por 14.11.2016 / 02:58
fonte