Desenvolvimento Guiado por Testes

37
Desenvolvimento Guiado por Testes Test-Driven Development (TDD) Guilherme Chapiewski http://gc.blog.br [email protected]

Transcript of Desenvolvimento Guiado por Testes

Page 1: Desenvolvimento Guiado por Testes

Desenvolvimento Guiado por TestesTest-Driven Development (TDD)

Guilherme Chapiewski http://gc.blog.br

[email protected]

Page 2: Desenvolvimento Guiado por Testes

O que é TDD?

Page 3: Desenvolvimento Guiado por Testes

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

Page 4: Desenvolvimento Guiado por Testes

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

Page 5: Desenvolvimento Guiado por Testes

Conceitos

Page 6: Desenvolvimento Guiado por Testes

Tipos de testes:

• Testes Unitários

• Testes de Integração

• Testes de Aceitação

Page 7: Desenvolvimento Guiado por Testes

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!

Page 8: Desenvolvimento Guiado por Testes

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

Page 9: Desenvolvimento Guiado por Testes

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

Page 10: Desenvolvimento Guiado por Testes

Demonstração

Page 11: Desenvolvimento Guiado por Testes

1. Definção da interface:

Page 12: Desenvolvimento Guiado por Testes

2. Criação do teste:

Page 13: Desenvolvimento Guiado por Testes

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

Page 14: Desenvolvimento Guiado por Testes

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

Page 15: Desenvolvimento Guiado por Testes

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

Page 16: Desenvolvimento Guiado por Testes

6. Programação do método:

Page 17: Desenvolvimento Guiado por Testes

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

Page 18: Desenvolvimento Guiado por Testes

8. Refactoring:

Page 19: Desenvolvimento Guiado por Testes

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

Page 20: Desenvolvimento Guiado por Testes

10. Corrigindo o refactor:

Page 21: Desenvolvimento Guiado por Testes

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)

Page 22: Desenvolvimento Guiado por Testes

Exemplos reais

Page 23: Desenvolvimento Guiado por Testes

Exemplo 1:

Page 24: Desenvolvimento Guiado por Testes

Exemplo 2:

Page 25: Desenvolvimento Guiado por Testes

Exemplo 3:

Page 26: Desenvolvimento Guiado por Testes

Consequências

Page 27: Desenvolvimento Guiado por Testes

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

Page 28: Desenvolvimento Guiado por Testes

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

Page 29: Desenvolvimento Guiado por Testes

Consequências:

Integração contínua

Page 30: Desenvolvimento Guiado por Testes

Consequências:

Integração contínua

Page 31: Desenvolvimento Guiado por Testes

Conclusões

Page 32: Desenvolvimento Guiado por Testes

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

Page 33: Desenvolvimento Guiado por Testes

Conclusões:

Demora mais?

Page 34: Desenvolvimento Guiado por Testes

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!

Page 35: Desenvolvimento Guiado por Testes

Perguntas?

Page 36: Desenvolvimento Guiado por Testes

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/

Page 37: Desenvolvimento Guiado por Testes

Obrigado!