Boas práticas com TDD: 1) Crie apenas os testes necessários e evite acrescentar asserts desnecessários. 2) Dê nomes específicos e diretos aos métodos de teste e evite underscore. 3) Entenda a diferença entre objetos e primitivos para usar asserts corretamente.

1. Boas Práticas com TDD
Camilo Lopes
@camilolope

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Books

16. OBRIGADO!!!