TDD: um processo de design

Palestra sobre TDD.

Transcript

1. TDD: um processo de design Renan Taranto
2. 2 Renan Taranto • Analista e Desenvolvedor na empresa Jungle • Especialista em arquitetura e design OOP • Github: https://github.com/renan-taranto • Email: renantaranto@gmail.com
3. 3 Introdução De uma vez por todas: TDD é um processo de DESIGN
4. 4 Por que TDD? • Código mal escrito escrito está por toda parte e não há documentação que os salve – Custos • Ajuda a criar melhores designs – DI, DRY, SOLID, YAGNI, KISS, etc.. – Código bem escrito é mais fácil de ser testado – Estimula a criação de boas APIs – Refatoração permite que o design evolua • Foco • Alta cobertura de testes • Reduz em 40-80% o número de bugs (http://evidencebasedse.com/? q=node/78 ) • Os testes se tornam uma espécie de documentação que não mente
5. 5 Por que TDD? • Aumenta a produtividade a longo prazo • Reduz demandas por suporte “Tests are as important to the health of a project as the production code is. Perhaps they are even more important, because tests preserve and enhance the flexibility, maintainability, and reusability of the production code” Robert C. Martin (Uncle Bob)
6. 6 Por que muitos não utilizam? • OOP do jeito certo não é fácil • Acreditam que um tester na equipe é suficiente • Falta de prática • Acreditam que é um processo que toma muito tempo
7. 7 O ciclo 1) Escrever um teste que falhe (RED) 2) Escrever o mínimo de código para que o teste passe (GREEN) 3) Refatorar
8. 8 Iniciando com TDD • Calma, tempo, e um projeto novo onde é possível experimentar • Framework de testes – Ex.: Junit, Nunit, PHPUnit… • Dois chapéus
9. 9 Iniciando com TDD
10. 10 Iniciando com TDD
11. 11 Iniciando com TDD
12. 12 Iniciando com TDD
13. 13 Iniciando com TDD
14. 14 Mocks e Stubs
15. 15 Mocks e Stubs
16. 16 Mocks e Stubs
17. 17 Mocks e Stubs
18. 18 Considerações Finais • Nenhuma linha de código de produção deve ser escrita antes de escrever um teste que cubra esta linha e falhe inicialmente • Testes unitários, funcionais, de aceitação… – Data Fixtures • Garantir que os testes passem antes de subir pra produção – CI, Docker, etc.. • Os testes devem ser tão bem escritos quanto código de produção
19. 19 Dúvidas ?
20. 20 Até a próxima! Obrigado!