TDD - Test Driven Development não é a bala de prata da qualidade de software, mas pode trazer benefícios se bem aplicado. O processo envolve escrever um teste pequeno antes do código funcional correspondente e refatorar continuamente. Isso força o pensamento no requisito antes de codificar e entrega código limpo e funcional, coberto por muitos testes. Porém, requer entendimento do problema, manutenção dos testes e não substitui outras práticas de teste.

1. TDD - Test Driven
Development
A Bala de Prata da qualidade de software?

2. História, O que é, O que não é
"Desenvolvimento orientado a testes" é um processo
focado no constante ciclo:
1. escreva um pequeno teste que descreva a feature
desejada
2. desenvolva o menor trecho possível de código para que
o teste passe
3. refatore o código para torná-lo decente

3. História, O que é, O que não é
● "Test Driven Development: By
Example" de Kent Beck, em 2003,
falando sobre metodologias ágeis
● TDD é usado em conjunto com outros
conceitos como extreme programming
● TDD definido por seus principais
objetivos:

4. História, O que é, O que não é
TDD é especificação, não validação

5. História, O que é, O que não é => Especificação, não validação
● TDD usa as boas práticas de testes unitários para
proporcionar e forçar o desenvolvedor a pensar no
requerimento ou design antes de escrever código
funcional
● “Entrega” testes unitários que ajudam na validação, mas
isso é só uma boa consequência da prática

6. História, O que é, O que não é
TDD entrega código limpo e funcional

7. História, O que é, O que não é => Código limpo e funcional
● Premissa que o desenvolvedor sempre vai escrever o
teste antes especificando o comportamento e trabalhar
no menor trecho de código funcional possível
● Menos linhas de código = menos bugs
● Mais testes = mais confiança e liberdade ao refatorar

8. Comofaiz?! Boas práticas com TDD
Para termos o processo realmente funcional precisamos
obedecer algumas pequenas mas importantes regras:
● O teste vem primeiro!
● Mantenha o código funcional pequeno, abuse de OO
● Trate seus testes com o mesmo respeito do seu código

9. Comofaiz?! Boas práticas com TDD
● O teste realmente precisa vir primeiro!
● Evite dependência entre testes, são partes autônomas
● Rode testes isolados, randomize quando rodar todos
● Use dados de fácil compreensão, cuide a legibilidade
● Crie testes que sejam um pequeno passo da feature
completa, quando juntos eles cobrirão todo o código

10. Prós e Contras. Bom, mau e feio
Parece tudo muito bom, tudo muito bem, seguindo as
práticas e entendendo do que se trata eu consigo fazer,
mas antes de fazer quero saber dos resultados!

11. Prós e Contras => Bom
● Pequeno passo, teste que ele está ok, próximo pequeno
passo. Muito código coberto por testes
● Código aos poucos > montes de código = produtividade
● Menos tempo de debug = produtividade
● Segurança para os desenvolvedores em refactors de
código antigo e manutenibilidade

12. Prós e Contras => Mau
● É necessário bom entendimento do requerimento
● É parte da suite de testes, mas não é toda a suite
● Testes precisam ter manutenção, são parte do projeto,
escreva-os bem
● Evite over-testing, quando o teste começa a ficar muito
grande procure quebrá-lo em mais testes

13. Prós e Contras => Feio
● Acreditar que TDD “são só alguns testes”
● Ignorar a manutenção dos testes
● Acreditar que TDD substitui testes de integração,
aceitação ou mesmo a documentação do projeto
● Testar depois de implementar a feature completa e achar
que isso “é só o que precisa pra ser agile com qualidade”

14. Beija ou Passa?
TDD é somente uma prática complementar de muitas boas
práticas de desenvolvimento de software.
Ele se vale de benefícios de testes unitários e da prática de
escrever pouco código para refatorar.
Deve ser adotado com apoio gerencial e cuidado dos
desenvolvedores para seguir as regras esperadas.
Com atenção e feito da maneira certa aumenta a
produtividade e a qualidade do projeto de software.

15. TDD - Test Driven Development => Não é bala de prata, mas também vale muito!
OBRIGADO!
miguelgraz.com