Melhorando o entendimento de testes com RSPEC

em Desenvolvimento, Geral.

Trabalho com Ruby há alguns anos e sempre utilizei RSPEC para fazer os testes dos projetos. Desde sempre, tentei aplicar as boas práticas de programação, como o DRY, nos códigos de teste. Isso ajudaria numa possível refatoração ou alteração dos testes.

Para isso, aprendi a usar coisas como o let, subject do RSPEC, que ajudam a reduzir a duplicidade (DRY) do código.

Com essas ferramentas realmente conseguimos deixar os testes bem mais enxutos e “bonitos”, mas não tínhamos a noção do pior.

Passado um tempo, quando se tenta rever esses testes, pode ser difícil entender o que está acontecendo, pois o código acaba não sendo linear.

Um exemplo abaixo:

Para entender o que a linha 12 está testando, é necessário seguir o seguinte fluxo:

  • O is_expected da linha 12 pega o resultado do subject, que está na linha 7
  • O subject da linha 7 pega o range_start da linha 10 (pois está dentro do contexto)
  • O subject da linha 7 pega o range_end da linha 3

E assim por diante…

Os testes deveriam ser de simples compreensão pois eles nos ajudam a entender o porquê de algumas implementações em alguns casos, e acabam servindo como documentação. Sendo difíceis de entender, não atingem esse objetivo.

Um jeito mais fácil de fazer esse teste seria assim:

Desse jeito fica muito mais claro entender o que está sendo feito no teste. Claro que perdemos o DRY se tivermos outro IT, pois várias coisas irão se repetir, mas acho que vale muito mais a clareza e a boa comunicação através de cada uma das especificações.

Vale comentar sobre o estilo de teste usado, conhecido como xUnit, que aprendi com o pessoal da Plataformatec, e tem mais detalhes neste link.

Como aprendizado, fica refletirmos quando vale a pena ou não utilizar esse tipo de abordagem. Em alguns casos, podemos ter repetições que podem ser resolvidas com um before ou até definindo um helper method que facilita a compreensão do código.
Confira mais detalhes nos artigos Improve your test readability using the xUnit structure, Let’s Not e What does “DAMP not DRY” mean when talking about unit tests?