BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Recomendações para Testes Unitários Melhores

por Mark Levison , traduzido por Marcelo Andrade em 27 Jul 2009 |

Jimmy Bogard escreveu um artigo intitulado“ Getting value out of your unit tests ”, em que aponta três regras:

  1. Os nomes dos testes devem descrever o 'o que' e o 'porquê' a partir da perspectiva do usuário” – a ideia é que o desenvolvedor deveria ser capaz de ler o nome do teste e entender qual o comportamento esperado imediatamente.
  2. Os testes são códigos também, trate-os com amor” – código-fonte em produção não é o único local em que você deve fazer suas refatorações. Testes legíveis são mais fáceis de se manter e mais fáceis de serem compreendidos por outras pessoas. “Eu detesto, destesto testes longos e complexos. Se você tem um teste com 30 linhas de configuração (setup), por favor, coloque-a em um método de criação. Um teste longo é irritante e confunde o desenvolvedor. Se eu não tenho métodos longos no código em produção, por que eu deixaria que eles existam nos códigos de nossos testes?”
  3. Não se atenha em um padrão ou estilo organizacional para fixtures” – Às vezes, mesmo tendo uma padronização para suas classes, pode ser que não tenha como aplicá-la a seus fixtures.

Lior Friedman complementa: “Regra #0 – Teste o comportamento externo e não a estrutura interna.” Quer dizer, teste as expectativas de uma classe e não sua estrutura atual.

Ravichandran Jv incluiu suas próprias regras:

    1. Uma assertiva (assert) por teste (sempre que possível). 
    2. Se houver qualquer condicional dentro de um teste, mova os blocos do "if" e do "else" para métodos individuais. 
    3. No caso de os métodos em teste também tiverem blocos if else, então o método deve ser refatorado.
    4. O nome do método deve ser um tipo de teste. Por exemplo, TesteFazerReserva() é diferente de TesteNaoFazerReserva().

Charlie Poole , autor do NUnit, re-escreve a regra de uma assertive por teste para uma “Assertiva Lógica” –dizendo “Algumas vezes, por uma falta de expressividade da api de testes, você precisa escrever várias assertivas para verificar o resultado esperado. Muito do desenvolvimento da api do framework NUnit tem sido uma tentativa de se fazer bastante coisa com que a regra da assertiva única.”

Bryan Cook  nos traz uma lista considerável de suas prórias regras:

  1. FAÇA: Nomeie seus fixtures consistentemente
  2. FAÇA: Imite os namespaces de seu código-alvo
  3. FAÇA: Nomeie os métodos de Setup/TeadDownName consistentemente
  4. CONSIDERE: Separar seus testes de seu código em produção
  5. FAÇA: Nomeie os testes depois da funcionalidade
  6. CONSIDERE: Usar o prefixo "Cannot" (ou “NaoPode”) para exceções esperadas

Bryan também discorre sobre mais uma dúzia de sugestões.

Por último, algumas pessoas sugeriram o livro de Gerard Meszaros:“ xUnit Test Patterns: Refactoring Test Code"

Anteriormente no InfoQ: Tutoriais TDD recomendados , Projetando para Testabilidade , Dicas do Google sobre Testes Unitários  e Fazendo TDD: Problemas e Soluções de quem já Adotou

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 mensagens dessa discussão
Comentários da comunidade

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

Receber mensagens dessa discussão

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

Receber mensagens dessa discussão

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