Desenvolvimento Guiado Por Testes

Desenvolvimento Guiado por Testes Test-Driven Development (TDD) Guilherme Chapiewski http://gc.blog.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

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

Motivação

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

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)‏
Ferramentas: JUnit, JMock/EasyMock
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+Fast, etc.)‏
Ferramentas: JUnit, DBUnit, HSQLDB, Fit
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
Ferramenta : JUnit, Selenium
Pode ser 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)‏

Consequências

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

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

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!

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/

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

http://gc.blog.br	494
http://www.slideshare.net	12

Desenvolvimento Guiado Por Testes

by Guilherme Chapiewski on Oct 30, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 506

Statistics

Desenvolvimento Guiado Por Testes — Presentation Transcript