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

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