Automatize testes

Mais um post da série de qualidade de código em teste de software

Se você está chegando neste post agora e ainda não leu os conteúdos anteriores, recomendo começar por eles. Seguem os links:

• Escreva pequenas unidades de código
• Escreva simples unidades de código
• Escreva código uma só vez
• Mantenha as interfaces da unidade pequenas
• Separe responsabilidades em módulos
• Acople a arquitetura de componentes fracamente
• Mantenha a arquitetura de componentes equilibrada
• Mantenha sua base de código pequena

Agora se você já leu os primeiros posts da série, vamos falar sobre a nona e penúltima guideline do Better Code Hub: Automatize testes.

Segundo o BCH:

• Automatizando testes sua base de código torna o desenvolvimento mais previsível e menos arriscado.
• Adicione testes para o código existente toda vez que mudá-lo.
• Se preocupe com a quantidade de código coberto por testes, sendo que para ser considerado um teste o mesmo deve possuir ao menos uma verificação (assertion).
• Se preocupe com a densidade de verificações (assertions).

Automatizando testes sua base de código torna o desenvolvimento mais previsível e menos arriscado

Projetos de software podem ficar fora de controle após algum tempo sem a preocupação adequada que testes automatizados merecem.

Como engenheiros de software, desenvolvedores, testadores, ou seja lá qual o cargo desde que escrevamos código, temos uma responsabilidade ética de manter o software soft, ou seja, fácil de ser alterado ao longo de sua “vida”.

É da natureza dos softwares nos dias de hoje que estes sejam alterados com frequência. Porém, precisamos garantir que o que já funcionava continua funcionando após quaisquer mudanças, visto que resultados inesperados podem incorrer em prejuízo financeiro, multas, problemas relacionados a questões legais, problemas de segurança, e não menos importante, diminuição da produtividade do time que desenvolve e entrega o software.

Visto que o código terá que ser modificado e não temos o que fazer com relação a isso, testes automatizados em diferentes níveis da aplicação se tornam essenciais para garantirmos que tais mudanças não quebraram nada, e mais importante, que caso tenham quebrado algo, saberemos disso rapidamente, e antes de entregar uma nova versão com bugs aos nossos usuários e/ou clientes.

Com relação a produtividade do time, testes automatizados apesar de terem um custo para serem escritos e mantidos, se pagam ao longo do tempo, visto que mudanças na aplicação se tornam mais seguras. É um investimento de longo prazo.

Adicione testes para o código existente toda vez que mudá-lo

Se você está alterando o software, para por exemplo, adicionar uma nova funcionalidade que resolve um problema de um grupo de usuários, ou para modificar outra funcionalidade que torna o trabalho de outro grupo de usuários mais fácil (por exemplo), lembre-se de cobrir tais mudanças com testes automatizados.

Lembre-se também de alterar ou remover testes já existentes. É isso mesmo, as vezes testes podem e devem ser descartados.

Mas como eu sei quais testes devo alterar ou remover?

Rode os testes e veja quais quebraram porquê você esqueceu deles quando estava fazendo sua implementação, e então você saberá.

Ou ainda melhor, escreva os testes antes da mudança propriamente dita, utilizando técnicas como TDD (desenvolvimento guiado por testes) ou BDD (desenvolvimento guiado pelo comportamento), assim você começará com um teste falhando, mas quando sua suite de testes estiver passando, você saberá que cobriu os cenários mais importantes.

Além disso, lembre de não testar detalhes de implementação. Em vez disso, testes como as diferentes partes do software se comportam baseados nos inputs que podem receber e seus possíveis outputs.

Se preocupe com a quantidade de código coberto por testes

Uma boa forma de confiar que as mudanças na aplicação realmente não quebraram nada é ter 100% de cobertura de código, pensando em testes em diferentes camadas do sistema (unidade, componentes, APIs, contratos, funcionais, end-to-end, testes de regressão visual, performance, segurança, etc.)

Mas vale lembrar que automação de tarefas e automação de testes são coisas diferentes. Ou seja, não adianta exercitar a aplicação em teste sem verificar ao final que ela funciona conforme o esperado, dadas as pré-condições e ações.

Vou tentar explicar melhor.

Vamos imaginar testes funcionais para uma aplicação web, onde precisamos garantir que a funcionalidade de login funciona via interface gráfica. Vejamos dois cenários:

Cenário 1:

Automatizamos os seguintes passos:

1. O usuário visita a página de login navegando pela URL.
2. O usuário preenche o formulário de login com dados (supostamente) válidos e submete o formulário.

Cenário 2:

Automatizamos os seguintes passos:

1. O usuário visita a página de login navegando pela URL.
2. O usuário preenche o formulário de login com dados (supostamente) válidos e submete o formulário.
3. Uma verificação é realizada para garantir que o usuário foi logado com sucesso.

Perceba que no cenário 1, se o login funcionar, ou se ocorrer algum erro na submissão do formulário, o script não irá falhar, visto que ele não espera que nada ocorra após tal ação.

Já no cenário 2, se algo der errado, a verificação de que o usuário foi logado com sucesso irá falhar, provendo o feedback que precisamos para saber que quebramos algo que já funcionava, e então corrigir antes de seguir adiante.

Muitos times se enganam achando que tem 100% de cobertura de código, quando na verdade possuem vários scripts que não verificam nada. Cuidado para não “cair” nessa você também!

Se preocupe com a densidade de verificações/asserções

Testes end-to-end são normalmente devagares de serem executados, visto que simulam um usuário real interagindo com a aplicação, e portanto, as vezes pode valer a pena considerar que estes executem mais de uma ação, e até mesmo mais de uma verificação. Vejamos de novo o exemplo do login.

No cenário do teste de login com sucesso, podemos verificar, por exemplo, que o avatar do usuário é exibido na tela, como também que uma mensagem de boas vindas é exibida.

Já quando falando de testes de unidade, estes podem ser executados em questão de milisegundos, e portanto, devem possuir apenas uma asserção por testes, o que também facilita em saber exatamente o que quebrou quando o teste falha.

O principal ponto aqui é que queremos o feedback mais rápido possível se mudanças na aplicação quebrarm algo que já funcionava, e portanto, temos que arquitetar nossos testes de forma que isso seja possível.

Adicione testes para bugs quando os estiver corrigindo (não citado pelo BCH)

Um ponto não especificamente citado pelo Better Code Hub, mas que considero essencial, é que adicionemos testes automatizados quando bugs estiverem sendo corrigidos. Assim, garantimos que eles não voltarão a acontecer, e que caso ocorram, saberemos disso antes de nossos usuários.

E com uma base sólida de testes automatizados nos quais você confia, fica mais fácil limpar o código.

---

Por falar nisso, o próximo e último post da série será: Escreva código limpo. {🧹}

Até a próxima e bons testes! 👋🧐