BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias TDD: Nomes de testes expressivos

TDD: Nomes de testes expressivos

Uma exigência cada vez mais comum aos desenvolvedores da atualidade é que os mesmo façam testes sobre o que produzido por eles. Não apenas com o intuito de garantir que as coisas funcionam ou de garantir que o desenvolvedor é um profissional de verdade, mas também de garantir que num futuro próximo pessoas novas na equipe tenham a capacidade de entender como as coisas funcionam a partir dos testes.

E quando fala-se de testes de unidade, umas das preocupações a serem tomadas é garantir que quando os testes falharem eles "digam" exatamente o que fazem, ou seja, qual tipo de comportamento estavam testando. Uma das coisas mais frustante em testes de unidade é encontrar testes que não trazem nenhuma informação de valor quando falham.

Recentemente o Mark Needham postou falando sobre uma das coisas mais importantes que deve-se considerar quando se vai escrever um teste de unidade: O nome do teste.

Mark disse que antigamente ele não importava-se com o nome dos testes pois ele acreditava que poderia obter a informação que queria simplesmente lendo o teste:

Eu não estava realmente incomodado com os nomes dos meus testes porque eu poderia entender o que eu queria lendo o corpo do teste.

Mark porém diz que recentemente teve que mudar alguns testes que testavam algumas coisas erradas, e por terem nome genéricos, ele não conseguiu entender o que estava acontecendo:

Recentemente, entretanto, eu estava fuçando vários testes que eu havia escrito anteriormente e que testavam coisas erradas e tinham nomes genéricos, e não era óbvio o que estava acontecendo.

Em um post, Jimmy Bogard diz que os nomes dos testes devem dizer o "o que" e o "por que" estão testando:

Umas das maneira para fazer isto facilmente é a nomeação por Contexto/Observação...Mas a idéia geral é que um desenvolvedor de fora deverua ser apto a ler o nome do teste, e entender claramente quão o comportamente é, para um dado contexto. Aqui está um mau exemplo:
public void validationShouldWorkCorrectly()
Validação deveria funcionar corretamente. Hmm. "Corretamente" ao olho do espectador. "Corretamente" depende de circustâncias. "Corretamente" depende da sua definição de "correto". A questão é, se este teste falhar no futuro, como eu sabarei se é porque o teste está errado ou o código está errado? Eu não saberei. E neste ponto, eu terei que fazer um julgamento para saber se o teste está ou não certo. Algumas vezes, eu apenas o farei passar, algumas vezes eu removerei o teste, e algumas vezes eu gastarei boa parte do meu tempo tentando descobrir o porquê do teste ter sido escrito primeiro.

Esse é possivelmente o aspecto mais frustrante. Um teste de unidade que foi supostamente para fornecer valor quando ele falha, ao invéz disso causa confusão e pavor.

Mark chegou a conclusão que testes devem ter seus nomes bem definidos, mesmo que testem as coisas erradas, o nome pode ajudar a entender o que ele realmente deveria fazer.

Eu acho que nomear testes dessa maneira pode ser completamente útil, então eu estou tentando e escrevendo a maioria dos meus testes como estes.

Claro que é possível ainda testar coisas erradas mesmo se você está usando nomes mais expressivos, mas eu acho que será menos provável.

Você acha que testes sem nomes que sejam expressivos podem se tornar um peso morto na sua aplicação? O quão exigente você é quanto a nomenclatura de seus testes?

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT