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

O que é TDD?

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

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

Conceitos

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

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!

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

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

Demonstração

1. Definção da interface:

2. Criação do teste:

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

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

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

6. Programação do método:

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

8. Refactoring:

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

10. Corrigindo o refactor:

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)

Exemplos reais

Exemplo 1:

Exemplo 2:

Exemplo 3:

Consequências

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

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

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

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

Conclusões

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

Conclusões:
 Demora mais?

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!

Perguntas?

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/

Obrigado!