O documento descreve os conceitos e benefícios do Desenvolvimento Guiado por Testes (TDD), incluindo suas regras fundamentais, ciclo de desenvolvimento, tipos de testes, e consequências como código mais testável e integração contínua.

1. Desenvolvimento Guiado por Testes Test-Driven Development (TDD) Guilherme Chapiewski http://gc.blog.br

2. O que é TDD?

3. Regras fundamentais do TDD: Escreva o teste da implementação ANTES de escrevê-la Escreva somente código suficiente para o teste passar e nada além disso Escreva testes pequenos: teste a menor quantidade possível de código de cada vez Escreva testes muito rápidos: não devem demorar mais do que alguns segundos para serem executados

4. Ciclo do desenvolvimento com TDD: Criar um teste Executar todos os testes da aplicação para ver o novo teste falhar Escrever a implementação testada Executar os testes para ver se todos passarão Refactoring Executar os testes novamente para garantir que eles continuam passando

5. Motivação

6. Motivações para adoção de TDD: Design pouco testável Baixa cobertura de testes unitários Necessidade de “levantar” todo o ambiente para desenvolver e testar Necessidade de manter compatibilidade retroativa Insegurança ao modificar base de código

7. Conceitos

8. Tipos de testes: Testes Unitários Testes de Integração Testes de Aceitação

9. 1. Testes Unitários: Testam apenas um componente do sistema Todos os outros componentes são simulados (mock objects)‏ Ferramentas: JUnit, JMock/EasyMock Fundamental para a prática do TDD!

10. 2. Testes de Integração: Testam a integração entre componentes Envolvem dois ou mais componentes (classes+SGBD, classes+SGBD+Fast, etc.)‏ Ferramentas: JUnit, DBUnit, HSQLDB, Fit Normalmente não utilizado em TDD

11. 3. Testes de Aceitação: Testam uma história, funcionalidade ou caso de uso Envolvem vários componentes do sistema Ferramenta : JUnit, Selenium Pode ser utilizado em TDD

12. Demonstração

13. 1. Definção da interface:

14. 2. Criação do teste:

15. 3. Execução do teste: (deve falhar pois sequer há implementação)‏

16. 4. Criação da classe de implementação: (somente o esqueleto da classe retornando sempre o mesmo resultado)‏

17. 5. Execução do teste: (falhou porque a implementação desenvolvida sempre retorna FALSE)‏

18. 6. Programação do método:

19. 7. Execução do teste: (teste passou: 100% de certeza que o código funciona!!!)‏

20. 8. Refactoring:

21. 9. Execução do teste: (teste falhou por distração do programador: não verificou se cep é nulo!!!)‏

22. 10. Corrigindo o refactor:

23. 11. Execução do teste: (teste passou: temos 100% de certeza que o código CONTINUA funcionando e que nenhum componente que depende deste código quebrou após o refactor)‏

24. Consequências

25. Consequências: Suite de regressão Testes completos sendo executados no build: aplicação não sobe para produção se não passar no teste de regressão Testes também pode ser feitos na IDE Não há necessidade de deploy da aplicação para execução dos teste s Bugs são encontrados com maior facilidade e corrigidos com maior velocidade Bugs comprovados por testes unitários

26. Consequências: Código mais testável Estimula um design melhor Força que os designs antigos que são pouco testáveis sejam refatorados Facilita o refactoring Evita “overdesign” Só se escreve código suficiente para o teste passar Evita que o desenvolvedor fique tentando adivinhar o futuro Colabora com a documentação

27. Consequências: Integração contínua

28. Consequências: Integração contínua

29. Conclusões

30. Conclusões: Colabora para o aumento da qualidade dos sistemas Desenvolvedores ficam mais corajosos e confiantes ao programar! Software cresce de forma ordenada e com qualidade de design Software se adapta com mais facilidade a mudanças

31. Conclusões: Demora mais?

32. Conclusões: Demora mais? No início é necessário escrever muitos testes Depois da inércia a suite de regressão está pronta e escrevem-se menos testes Certeza de que a implementação está funcionando Maioria dos bugs encontrados em tempo de desenvolvimento Bugs de produção são encontrados e corrigidos com muito mais velocidade Então no fim das contas demora-se muito menos tempo e com muito mais qualidade!

33. Leitura complemetar: Introduction to TDD: http://www.agiledata.org/essays/tdd.html Desenvolvimento Orientado a Testes: http://www.improveit.com.br/xp/praticas/tdd Screencast TDD em ação: http://dojofloripa.wordpress.com/2007/05/21/screencast-tdd-em- acao/ Improve your unit tests by replacing your collaborators with mock objects: http://www.opensourcetutorials.com/tutorials/Server-Side-Coding/Java/java-unit-testing-with-mock-objects Behaviour-Driven Development: http://behaviour-driven.org/

34. Obrigado! Guilherme Chapiewski http://gc.blog.br