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

  • View
    106

  • Download
    1

Embed Size (px)

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

  • Slide 1
  • Test-Driven Development : uma viso prtica Leonardo Barros, M.Sc.
  • Slide 2
  • O que TDD? Test-Driven Development: Desenvolvimento Guiado por Testes Os testes so feitos ANTES da implementao, diferentemente da abordagem tradicional, em que os testes so feitos DEPOIS da implementao (*) A autoria comumente creditada a Kent Beck, embora o conceito no seja de todo original Referncias: 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, no obrigatrio que todos os testes precisem ser criados antes da implementao
  • Slide 3
  • Premissas do TDD Os testes so 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, no boa prtica testar questes de layout, como posicionamento ou cores
  • Slide 4
  • O Processo do TDD (exemplo com um mtodo 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
  • Slide 5
  • Exemplo de TDD com um mtodo simples
  • Slide 6
  • Especificao do mtodo /** * Emite um relatrio (array de Strings), indicando quantas vezes cada palavra * aparece no array fornecido. O relatrio apresentado na mesma ordem dos dados * de entrada, sendo que cada String representa uma palavra e seu nmero de * ocorrncias. Por exemplo, para a chamada: * * countWords(new String[] {"java","in","out","java","java","out"}) * * o relatrio gerado : * * ["java - 3", "in - 1", "out - 2"] * * @param words array com as palavras a serem contadas. * @return relatrio com o cada palavra e o nmero de repeties. */ String[] countWords(String[] words) { // }
  • Slide 7
  • Revisando o mtodo Requisito(s) atendido(s)? SIM O m todo est robusto? NO Pr ximos passos: construir mais testes para mapear aspectos no cobertos
  • Slide 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
  • Slide 9
  • Pontos positivos O desenvolvedor pode resolver o problema aos poucos, aspecto a aspecto Testes facilitam o entendimento/documentam dos requisitos Bugs so 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 testvel Consequentemente Refactorings so menos arriscados Revisando o processo (cont.)
  • Slide 10
  • Nova verso 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
  • Slide 11
  • Anlise Abordagem Tradicional Implementa o primeiro, testar depois o que foi feito Muitos bugs s so encontrados quando o desenvolvimento j foi encerrado Em caso de erros nas estimativas / presso entrega, testes so prejudicados Se houver poucos testes, refactorings so arriscados Tendncia a tornar o c digo gen rico (mais complexo do que necess rio) para evitar refactorings
  • Slide 12
  • Riscos/Dificuldades do uso de TDD Resistncia da equipe (mudan a de cultura) Negocia o do prazo com o cliente Estimativas / Acompanhamento do desenvolvimento
  • Slide 13
  • Potenciais benefcios do uso de TDD Maior facilidade de evolu o do projeto Mudan as/novos requisitos so menos amea adores C digo mais simples Rotatividade causa menos impacto Testes cobrem/documentam as principais funcionalidades C digo mais leg vel
  • Slide 14
  • JUnit muito bom, mas No 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?
  • Slide 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 no haja balas de prata )
  • Slide 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 Referncia: http://fest.easytesting.org/swing/wiki/pmwiki.php
  • Slide 17
  • Anlise da ferramenta Pontos fortes Open Source (licena Apache 2.0) Uso bastante intuitivo Extensvel Testes so escritos na mesma linguagem da implementao (Java) Comunidade bastante ativa Pontos fracos Documentao pobre Jovem (incio em meados de 2007)
  • Slide 18
  • Exemplo de TDD com uma janela Swing
  • Slide 19
  • Especificao da janela (Login) Deve conter pares r tulo/campo para conta e senha Deve conter um boto 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
  • Slide 20
  • At aqui tudo bem, mas E os problemas do Mundo Real ? Interfaces Gr ficas Arquitetura Cliente-Servidor Banco de Dados etc
  • Slide 21
  • Exemplo de TDD mais realista
  • Slide 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
  • Slide 23
  • Modelo de trabalho proposto (Correo 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
  • Slide 24
  • Modelo de trabalho proposto (Refactorings em cdigo 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 esto corretos 5. Reimplementar o m todo aos poucos, implementando a solu o mais simples para cada teste
  • Slide 25
  • FIM... ou o incio?