BT

TDD: Nomes de testes expressivos

por Lucas Souza em 23 Mar 2010 |

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?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

TDD: Nomes de testes expressivos by Joao Paulo Sossoloti

Ola... otimo post!
Talves uma das coisas que poderiam melhorar a legibilidade dos testes é adotar o BDD, pois assim cada teste ou conjunto tem uma forte característica e descrição...

Re: TDD: Nomes de testes expressivos by Hudson Leite

Finalmente alguém aborda um aspecto que eu acredito ser extremamente crítico quando se escreve testes. E independente de se você usa TDD ou BDD, o test ou o scenario deve identificar/contextualizar precisamente o que se pretente com o mesmo, para tanto eu costumo ser bastante prolixo na descrição de meus testes, chegando a colocar, extensivamente, a entrada (contexto), e a saída esperada.

TDD: Nomes de testes expressivos by Fernando Ribeiro

Muito bom post,
Realmente hoje em dia o teste pode dizer muito da aplicação e do seu desenvolvedor, existem muitas ferramentas que podem nos ajudar manter essa pratica, uma coisa importante abordada no artigo é o nome dos testes e realmente acho que o nome do teste deve dizer por si mesmo a sua funcionalidade isso poupa muito em linhas de comentários é também acaba com a necessidade de interpretar o código para descobrir o que ele faz

Re: TDD: Nomes de testes expressivos by Lucas Ap. Souza

Obrigado pelo comentários galera. Concordo com as opiniões mencionadas. Creio que o nome do teste seja de extrema importância para identificar o que ele realmente está testando, olhar o corpo do teste para ver o que ele testa é bem mais difícil. Não sei quem já fez testes de aceitação em java usando Selenium, lá se você não nomeia seus testes de maneira bem feita, é mto dificil entender o que ele faz.

Desprenda-se de convenções de nomenclatura em nome de testes by Prodis a.k.a. Fernando Hamasak...

Além de serem expressivos, você pode se desprender da convenção de nomenclatura de sua linguagem para obter maior legibilidade dos nomes dos testes.
Há um tempo atrás fiz um post falando a respeito.
Prodis' Blog: Desprenda-se de convenções de nomenclatura em nome de testes

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

5 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT