Tests Smells: Quando algo não cheira bem no seu teste. Parte I

E aí, QAs, vocês sabem o que são Tests Smells? Como vivem? Do que se alimentam? Como atrapalham nossa vida? Pois bem, se não sabe do que eu estou falando, sem problemas, continue aqui que vou explicar.

O que são Tests Smells?

Quem desenvolve software já deve ter ouvido em algum momento sobre Code Smells. Code Smells é um indício que algo no código não está legal. Pode ser a arquitetura, duplicação de código, alto acoplamento entre outras coisas. Em contrapartida, quando esses indícios são encontrados no código de teste, temos então os Tests Smells".

Mas pera aí…quer dizer que devemos nos preocupar com qualidade do código de teste? Com certeza! Sempre que fazemos um código de teste devemos observar as melhores práticas assim como no código de produção. Esse código também vai precisar de manutenção em algum momento.

Nesse artigo vou apresentar a vocês alguns exemplos de Tests Smells que você pode estar implementando no seu projeto e nem sabe. Vou apresentar aqui alguns casos que podem ser encontrados em diferentes níveis de testes como em testes de unidade, integração e UI.

Sleepy Test

Vou começar com um bem fácil e bastante comum. Se você que está lendo é uma pessoa que trabalha como QA, provavelmente já se deparou com um caso desse e, é até provável que já tenha feito um código assim. O Sleepy Test é quando adicionamos um tempo de espera fixo no nosso teste com o objetivo de parar a execução por alguns segundos antes de continuar os próximos passos. É o famoso Thread.sleep() (para quem é do mundo Java).

Vamos ver um exemplo rápido:

No código acima (um exemplo fictício de código com Selenium), na linha 4, temos o uso do Thread.sleep(). A intenção ali é de aguardar 5 segundos (5000 ms). Geralmente isso é feito porque o elemento a seguir (linha 5) demora um pouco para ser carregado e sem essa espera, uma exceção será lançada.

Mas se esperar o elemento carregar é necessário, por que isso é uma má prática ou um test smell? É o seguinte: esse código sempre irá aguardar 5s. Mas, talvez, o elemento que queremos interagir pode ficar pronto mais rápido. Então imagine que após o clique no primeiro elemento (linha 3) o elemento da linha 5 demore apenas 2s para ser carregado. Nosso código ficará parado mais 3s sem necessidade.

Poxa, mas 3s é pouco, passa rápido. Pode até ser se pensarmos apenas nesse testes isolado. Agora pare e pense, no seu projeto, quantos testes existem na sua suíte? Se cada um deles tiver uma espera desnecessária você acaba tendo problemas na sua pipeline com uma suíte de teste que demora muito. Lembre-se que queremos ter feedback o mais rápido possível.

Aqui usei de exemplo um caso de Sleepy Test num teste com Selenium, mas essas coisas podem acontecer em testes de unidade e de integração também. Então, QAs, que tal fazer uma revisão nos testes que as pessoas desenvolvedoras fazem?

Vou deixar dois links de como você pode remover esses sleeps do seu código. O primeiro link é para casos com o Selenium:

Waits

Já o segundo é para outros casos de esperas em códigos que não usam Selenium:

awaitility/awaitility

Unknown Test

Esse segundo Test Smell que apresento a vocês, eu encontro muito revisando testes de unidade, mas ele também pode ser encontrado em outros níveis. Unknown Test é um teste que você não sabe o que ele está validando, ele não possui uma asserção. Veja um exemplo:

O código acima foi copiado de um projeto público no GitHub. Apesar de poucas linhas de código, você consegue ler esse teste e me dizer o que ele está testando? Pois é, não dá para saber. Além do nome não ser claro sobre o que é esperado, não existe um assert nesse código.

É importante dar bons nomes para os nossos testes também e, claro, fazer validações, deixando o assert bem claro sobre o objetivo do teste. Veja um exemplo de um teste melhor escrito:

Nesse novo exemplo, já ficou mais claro o objetivo do teste não é mesmo? O nome do método deveSomarDoisNumerosInteiros() já ajuda a entender o objetivo do teste. E, por fim, mas não menos importante, o assert na linha 4 também deixa fácil o que é esperado.

Empty Test

E para finalizar esse artigo um caso simples que eu também já encontrei nos projetos que trabalhei. O problema aqui é tão claro, que vou direto ao exemplo:

Conseguem perceber o problema? Se tudo está comentado, para que esse teste existe? Já vi casos também que dentro do método de teste existia exatamente nada. Acho que deve ter alguém querendo manipular relatório de teste dizendo que fez um monte de teste, mas na verdade…é a única explicação que eu tenho para fazer uma coisa dessa e manter isso rodando na pipeline.

Conclusão

Escrever código de teste exige uma preocupação com a qualidade de como é escrito tão grande quanto escrever código de produção. Não só pela manutenção, mas também por legibilidade e transparência sobre o que está sendo testado ou não.

Existem, claro, muitos outros Tests Smells, e eu pretendo trazê-los em novos artigos, em breve, para não tornar esse aqui tão extenso. Você já se deparou com alguns desses casos que citei? Tem algum outro que conhece? Comenta aí.

Referências

Tests Smells — https://testsmells.org/pages/testsmellexamples.html

Revisores

Não posso deixar de agradecer mais uma vez ao Bruno Pulis, Gabriel Santos e Tainara Reis que prontamente me ajudaram na revisão.