Construindo um Framework de Automação de Testes: As Partes que Ninguém Orça

O que um framework de automação de testes realmente contém

Somam-se a isso relatórios que as pessoas realmente vão ler, configuração de ambiente, política de retentativas e uma forma de colocar um teste instável em quarentena sem perdê-lo. Os testes em si costumam ser a menor parte.

O custo oculto

Cada uma dessas peças é construída pela pessoa que montou o framework, em um estilo que só ela entende por completo. Quando essa pessoa sai, o framework vira algo que o time tem medo de mudar — e uma suíte que as pessoas têm medo de mudar é uma suíte que acaba em quarentena em vez de ser consertada.

Quando construir faz sentido

• Requisitos fora do comum. Um protocolo, plataforma ou exigência de conformidade que nenhuma solução pronta atende.

• Os testes são o centro do produto. Se você vende confiabilidade, ser dono dessa estrutura de execução pode ser estratégico.

• Você tem capacidade contínua. Não uma pessoa por um trimestre. Um dono por anos.

Quando não faz sentido

Se a razão honesta é que o time gosta de construir ferramentas, ou que uma avaliação pareceu inconclusiva, o framework vai ser construído e depois lentamente abandonado. Esse é o caso mais comum, e vale dar nome a ele antes do primeiro commit.

Sinais de que o framework virou o produto

Vale ter alguns sinais concretos, porque a transição é gradual e ninguém anuncia quando ela acontece.

Alguém pergunta como adicionar um teste e a resposta leva mais de dois minutos para ser explicada. Novas pessoas no time escrevem o primeiro teste copiando um existente e trocando valores, sem entender as fixtures por baixo. Uma falha de teste levanta a dúvida de se o framework mudou. Existe um arquivo que ninguém quer tocar. O trabalho no framework aparece no planejamento da sprint como item próprio, com regularidade.

Dois quaisquer desses sinais e você tem um produto com uma base de clientes internos de um time só. Isso não está automaticamente errado; muitas organizações fizeram essa escolha de forma deliberada. Só vira problema quando aconteceu sem ninguém ter escolhido, que é o caso de sempre.

O caminho do meio

Mantenha testes escritos à mão para os casos que você especificou deliberadamente e deixe a cobertura gerada cuidar da amplitude, com os problemas de sessão, dados, ordenação e limpeza resolvidos como parte do produto, e não como a sua infraestrutura.

A mesma configuração está disponível no dashboard da TestSprite, caso você prefira não instalar nada localmente. O restante da superfície do CLI está no repositório do CLI.

Se o pipeline pertence a outro time, o GitHub App é o caminho de menor resistência: é um webhook, não muda nada no seu repositório e dispara quando o seu build informa que a nova versão está no ar. Se você prefere que a verificação fique visível no repositório, um passo do GitHub Actions faz isso.

O que você recebe em vez de construir

As partes que iam virar a sua infraestrutura já vêm como produto. O Auto-Authentication mantém as sessões vivas ao longo de uma execução, as Dynamic Variables levam valores de uma chamada para outra, as Dependency Chains derivam a ordem de execução e o Auto-Cleanup remove exatamente o que a execução criou. Relatórios, configuração de ambiente e comportamento de retentativa vêm junto, então nada disso vira um arquivo que ninguém quer tocar.

A cobertura é gerada a partir do seu produto e refinada em linguagem simples, o que elimina a outra metade do custo: a parte em que cada teste precisa ser escrito por alguém cujo tempo é disputado.

O valor não está em dizer que construir é errado. Está no fato de que a maioria dos times nunca decidiu construir e descobre, no nono mês, que tem um produto com um único cliente interno. Manter os testes que você especificou deliberadamente e deixar que a estrutura de execução seja problema de outra pessoa é a versão disso que não acumula um dono que você nunca colocou no orçamento.