Boas práticas com TDD

1.089 visualizações

Publicada em

Boas Práticas com TDD

Publicada em: Tecnologia
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.089
No SlideShare
0
A partir de incorporações
0
Número de incorporações
6
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Boas práticas com TDD

  1. 1. Boas Práticas com TDD Camilo Lopes @camilolope
  2. 2. 1. Crie apenas os testes que precisa• É comum querer sair escrevendo vários testes por horas sem saber se realmente precisa de todos eles. A idéia é: crie apenas testes que agreguem valor, e para o que precisa validar no momento.
  3. 3. 2. Ns asserts• Aqui é quando um método tem vários asserts para cenários diferentes. Evite isso. Crie assert com base no tipo do teste que está criando; o assert tem que estar alinhado com o nome do teste. Mas não queira colocar vários asserts no mesmo teste.
  4. 4. 3. Nome de métodos confusos• Os nomes dos métodos de teste precisam ser específicos e diretos para o que se quer testar. Por exemplo: testIfListUserIsEmpty. Evite o underscore para separação.
  5. 5. 4. Saiba a diferença entre objetos e primitivos• Saber usar corretamente a igualdade com assert é importante, pois ajuda a entender melhor o teste. Se está testando objetos, use assertEquals, se é primitivo use asserTrue/False com o operador que deseja.
  6. 6. 5. Agregação de valor• Os testes precisam agregar valor, se não agregam valor para aplicação ele se torna um custo. Antes de escrever um teste veja se realmente ele é válido.
  7. 7. 6. Maldita Cobertura• Se você precisa escrever testes para atingir percentual de cobertura significa que os demais testes já criados não estão agregando tanto valor como deveria. A sugestão é: identifique os testes que não agregam valor e refatore ou remova. Isso terá um custo, mas é necessário, assim você aprenderá que é importante criar apenas os testes necessários.
  8. 8. 7. Bons testes• Agregam valor e a cobertura é conseqüência. E não há esforço extra para isso. Então lembre-se: não há separação entre cobertura e bons testes.
  9. 9. 8. A relação• Não há número ideal de quantos testes uma classe deve ter e não há relação alguma que quanto mais teste melhor a qualidade, o mais importante é o quanto o teste agrega valor.
  10. 10. 9. TDD não é receita de bolo• O fato de ter unit test no seu código não quer dizer que fez TDD. TDD vai além de unit test apenas.
  11. 11. 10. Use com moderação• Use o setup com moderação, apenas coloque lá aquilo que serão compartilhados por vários testes em cenários diferentes.
  12. 12. 11. Teste Cross• Evite criar testes que funcionam só em um determinado ambiente, ou seja, “em minha máquina funciona”. Seu teste deve rodar em qualquer ambiente que for executado e não ter dependências de ambiente.
  13. 13. 12. No comments• Evite de toda forma comentários no seu teste que explique o que ele faz. Caso você comece a escrever um comentário para explicar seu método, comece a apagá-lo, pois há um problema de legibilidade de código no ar.
  14. 14. 13. O jegue lerdo• É aquele teste lento para ser executado, onde podemos ir ao banheiro, tomar um café e pior, deixar rodando no final do dia e ir pra casa para podermos ver o resultado só no dia seguinte. Testes lentos é sinal de baixa qualidade. Descubra o gargalo e refatore.
  15. 15. Books
  16. 16. OBRIGADO!!!

×