Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Recomendações para Testes Unitários Melhores
Postado 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:
- “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.
- “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?”
- “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:
- Uma assertiva (assert) por teste (sempre que possível).
- Se houver qualquer condicional dentro de um teste, mova os blocos do "if" e do "else" para métodos individuais.
- No caso de os métodos em teste também tiverem blocos if else, então o método deve ser refatorado.
- 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:
- FAÇA: Nomeie seus fixtures consistentemente
- FAÇA: Imite os namespaces de seu código-alvo
- FAÇA: Nomeie os métodos de Setup/TeadDownName consistentemente
- CONSIDERE: Separar seus testes de seu código em produção
- FAÇA: Nomeie os testes depois da funcionalidade
- 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
Nenhum comentário
Acompanhar Discussão Responder