A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Test-Driven Development : uma visão prática Leonardo Barros, M.Sc.

Apresentações semelhantes


Apresentação em tema: "Test-Driven Development : uma visão prática Leonardo Barros, M.Sc."— Transcrição da apresentação:

1 Test-Driven Development : uma visão prática Leonardo Barros, M.Sc.

2 O que é TDD? Test-Driven Development: Desenvolvimento Guiado por Testes Os testes são feitos ANTES da implementação, diferentemente da abordagem tradicional, em que os testes são feitos DEPOIS da implementação (*) A autoria é comumente creditada a Kent Beck, embora o conceito não seja de todo original Referências: Beck, K. Test-Driven Development by Example, Addison Wesley, 2003 Link, J. Unit Testing in Java: How Tests Drive the Code, Morgan Kaufmann, 2003 (*) No TDD, não é obrigatório que todos os testes precisem ser criados antes da implementação

3 Premissas do TDD Os testes são definidos em fun ç ão dos requisitos A implementa ç ão é definida em fun ç ão dos testes Cada acr é scimo funcional precisa ser justificado por um teste (*) Busque sempre a implementa ç ão mais simples que atenda ao teste Se você acha que faltou algo no c ó digo, escreva mais um teste que justifique a complementa ç ão (*) Em geral, não é boa prática testar questões de layout, como posicionamento ou cores

4 O Processo do TDD (exemplo com um método simples) 1. Criar uma implementa ç ão vazia do m é todo ( casca ) 2. Criar um teste para mapear um ou mais requisitos ( é recomend á vel come ç ar simples) 3. Rodar o novo teste, para confirmar que este mapeia o(s) requisito(s) (Red Bar) 4. Implementar a solu ç ão mais simples que fa ç a todos os testes rodarem 5. Rodar os testes para verificar a implementa ç ão (Green Bar) 6. Simplificar a implementa ç ão, se poss í vel (Refactoring) 7. Repetir os passos 2 a 5 at é atender a todos os requisitos

5 Exemplo de TDD com um método simples

6 Especificação do método /** * Emite um relatório (array de Strings), indicando quantas vezes cada palavra * aparece no array fornecido. O relatório é apresentado na mesma ordem dos dados * de entrada, sendo que cada String representa uma palavra e seu número de * ocorrências. Por exemplo, para a chamada: * * countWords(new String[] {"java","in","out","java","java","out"}) * * o relatório gerado é: * * ["java - 3", "in - 1", "out - 2"] * words array com as palavras a serem contadas. relatório com o cada palavra e o número de repetições. */ String[] countWords(String[] words) { //… }

7 Revisando o método Requisito(s) atendido(s)? SIM O m é todo est á robusto? NÃO Pr ó ximos passos: construir mais testes para mapear aspectos não cobertos

8 Revisando o processo Pontos negativos Desenvolvimento é mais lento Mudan ç a de h á bito (inicialmente) Quem cria os testes é o desenvolvedor, portanto ambos os testes e o c ó digo de produ ç ão podem ter os mesmos erros conceituais A barra verde pode levar a uma falsa sensa ç ão de seguran ç a e fazer com que a equipe relaxe nos testes de integra ç ão e funcionais

9 Pontos positivos O desenvolvedor pode resolver o problema aos poucos, aspecto a aspecto Testes facilitam o entendimento/documentam dos requisitos Bugs são percebidos mais cedo É mais f á cil identificar a causa A corre ç ão é menos custosa O aprendizado é melhor Garante uma boa base de testes A arquitetura tende a apresentar baixo n í vel de acoplamento O c ó digo é, naturalmente, facilmente testável Consequentemente … Refactorings são menos arriscados Revisando o processo (cont.)

10 Nova versão 1. Novo requisito: case-insensitive 1. Basta criar novo teste 2. Mudan ç a no requisito: deve-se ordenar do maior para o menor, com os n ú meros na frente 1. Deve-se primeiro ajustar os testes, para em seguida ajustar a implementa ç ão 2. Se encontrar uma solu ç ão geral for complicado, comente os testes e v á progressivamente restabelecendo-os 3. Refactoring

11 Análise Abordagem Tradicional Implementa ç ão primeiro, testar depois o que foi feito Muitos bugs s ó são encontrados quando o desenvolvimento j á foi encerrado Em caso de erros nas estimativas / pressão entrega, testes são prejudicados Se houver poucos testes, refactorings são arriscados Tendência a tornar o c ó digo gen é rico (mais complexo do que necess á rio) para evitar refactorings

12 Riscos/Dificuldades do uso de TDD Resistência da equipe (mudan ç a de cultura) Negocia ç ão do prazo com o cliente Estimativas / Acompanhamento do desenvolvimento

13 Potenciais benefícios do uso de TDD Maior facilidade de evolu ç ão do projeto Mudan ç as/novos requisitos são menos amea ç adores C ó digo é mais simples Rotatividade causa menos impacto Testes cobrem/documentam as principais funcionalidades C ó digo é mais leg í vel

14 JUnit é muito bom, mas… Não basta! Em uma arquitetura cliente-servidor, posso utilizar o JUnit para testar a constru ç ão dos m é todos do servidor (testes unit á rios), mas e a interface gr á fica do cliente? Como fa ç o testes funcionais?

15 Você precisa de boas ferramentas! TDD é um processo teoricamente poss í vel de ser realizado sem ferramentas - na pr á tica, é invi á vel Existem diversas ferramentas que auxiliam em cada caso (embora não haja balas de prata )

16 Exemplo de ferramenta: FEST-Swing Focada em testes realizados sobre uma interface gr á fica Swing (Java) Um dos m ó dulos de uma cole ç ão de APIs criada para simplificar o processo de teste Referência:

17 Análise da ferramenta Pontos fortes Open Source (licença Apache 2.0) Uso bastante intuitivo Extensível Testes são escritos na mesma linguagem da implementação (Java) Comunidade bastante ativa Pontos fracos Documentação pobre Jovem (início em meados de 2007)

18 Exemplo de TDD com uma janela Swing

19 Especificação da janela (Login) Deve conter pares r ó tulo/campo para conta e senha Deve conter um botão Entrar que ir á validar o login e exibir uma mensagem de bem vindo ao sistema Em caso de conta ou senha errada, deve exibir uma mensagem login inv á lido ao usu á rio

20 Até aqui tudo bem, mas… E os problemas do Mundo Real ? Interfaces Gr á ficas Arquitetura Cliente-Servidor Banco de Dados etc

21 Exemplo de TDD mais realista

22 Modelo de trabalho proposto (Desenvolvimento) 1. Defini ç ão de requisitos 2. Prototipa ç ão 3. Testes de Aceita ç ão iniciais (automatizar se poss í vel) 4. Defini ç ão Arquitetura inicial 5. Testes Funcionais iniciais (automatizar se poss í vel) 6. Desenvolvimento 1. Defini ç ão interfaces 2. Testes unit á rios 3. Implementa ç ão 7. Testes de Intera ç ão

23 Modelo de trabalho proposto (Correção de bugs) 1. Reprodu ç ão manual do problema 2. Implementa ç ão de teste autom á tico (ou manual, se o custo for muito alto) 3. Executar teste para garantir que o problema é capturado 4. Corrigir problema 5. Executar teste para garantir que o problema foi resolvido

24 Modelo de trabalho proposto (Refactorings em código sem testes) 1. Levantamento dos requisitos da interface 2. Implementa ç ão de testes autom á ticos (ou manuais, se o custo for muito alto) 3. Ler o c ó digo atual para garantir que todos os aspectos foram tratados (se necess á rio, escrever mais testes) 4. Rodar testes para garantir que estão corretos 5. Reimplementar o m é todo aos poucos, implementando a solu ç ão mais simples para cada teste

25 FIM... ou o início?


Carregar ppt "Test-Driven Development : uma visão prática Leonardo Barros, M.Sc."

Apresentações semelhantes


Anúncios Google