1. Desenvolvimento
Guiado por Testes
Test-Driven Development (TDD)
Guilherme Chapiewski
http://gc.blog.br
gc@mandic.com.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. Etapas da programação com TDD:
1. Criar um teste
2. Executar todos os testes da aplicação para ver
o novo teste falhar
3. Escrever a implementação testada
4. Executar os testes para ver se todos passarão
5. Refactoring
6. Executar os testes novamente para garantir
que eles continuam passando

5. Conceitos

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

7. 1. Testes Unitários:
 Testam apenas um componente do sistema

Todos os outros componentes são simulados
(mock objects)

Ex. ferramentas: JUnit, JMock

Fundamental para a prática do TDD!

8. 2. Testes de Integração:
 Testam a integração entre componentes

Envolvem dois ou mais componentes
(classes+SGBD, classes+SGBD+webservices,
vários layers da aplicação, etc.)

Ex. ferramentas: JUnit, DBUnit, HSQLDB

Normalmente não utilizado em TDD

9. 3. Testes de Aceitação:
 Testam uma história, funcionalidade ou caso de
uso

Envolvem vários componentes do sistema

Ex. ferramentas: JUnit, Selenium, Fit/FitNesse

Utilizado em TDD

10. Demonstração

11. 1. Definção da interface:

12. 2. Criação do teste:

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

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

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

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

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

18. 8. Refactoring:

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

20. 10. Corrigindo o refactor:

21. 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)

22. Exemplos reais

23. Exemplo 1:

24. Exemplo 2:

25. Exemplo 3:

26. Consequências

27. Consequências:
 Suite de regressão
 Testes completos podem ser 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 testes
 Bugs são encontrados com maior facilidade e corrigidos
com maior velocidade
 Bugs comprovados por testes unitários

28. 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 tente adivinhar o futuro
 Colabora com a documentação

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

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

31. Conclusões

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

33. Conclusões:
 Demora mais?

34. 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!

35. Perguntas?

36. Leitura complementar:
 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/

37. Obrigado!