BT

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

Contribuir

Tópicos

Escolha a região

Início Notícias Recomendações para Testes Unitários Melhores

Recomendações para Testes Unitários Melhores

This item in japanese

Favoritos

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

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT