Pensando 
TDD 
08/10/2014
Direitos Autorais 
Você está autorizado e incentivado a distribuir este material. 
Copie, compartilhe e modifique, apenas ...
Autoria 
Luiz Ricardo 
luizricardo.org 
facebook.com/StateOfTheArtBlog
Código-fonte 
O código dos exemplos práticos pode ser obtido no link: 
https://github.com/utluiz/tdd-example
Porque software?
$$$???
Software de Qualidade 
Faz o que deveria fazer 
SEM ERROS
Software de Qualidade 
Funciona
Dificuldades do Software 
Abstrato 
Sem representação visível 
Dificuldade em identificar requisitos
Dificuldades do Software 
Singular 
Cada um é diferente
Dificuldades do Software 
Mutável 
1 bit muda tudo
Dificuldades do Software 
Complexo 
Simplificação 
Perda de informação
Expectativa Realidade
Como fazer software 
de qualidade?
Teste Teste 
Teste 
Teste 
Teste
TDD 
Test-Driven Development 
Metodologia ágil de 
desenvolvimento de software 
cujo objetivo é gerar 
código limpo que fu...
Fases do Desenvolvimento 
Tradicional 
Projeto 
Implementação 
Teste
Mudanças acontecem...
Correção de Bugs 
Custo por fase 
Design Implementação Teste Manutenção
Fases do Desenvolvimento 
TDD 
Projeto/Teste 
Implementação
Definição de “Pronto” 
Quando terminamos uma nova 
funcionalidade?
Definição de “Pronto” 
Código
Definição de “Pronto” 
Código limpo
Definição de “Pronto” 
Código limpo 
Testado
Definição de “Pronto” 
Código limpo 
Teste automatizado
Definição de “Pronto” 
Código limpo 
Teste automatizado 
Deploy automatizado
Definição de “Pronto” 
Código limpo 
Teste automatizado 
Deploy automatizado 
Documentado
Ciclo de Vida do TDD 
Vermelho 
Refatore Verde
Ciclo de Vida do TDD 
O “Mantra” 
Vermelho, verde, refatore 
Vermelho, verde, refatore 
Vermelho, verde, refatore 
Vermelh...
Ciclo de Vida do TDD 
Vermelho 
1. Escreva um 
teste que falhe 
Refatore Verde
Ciclo de Vida do TDD 
Vermelho 
1. Escreva um 
teste que falhe 
Refatore Verde 
2. Faça 
funcionar
Ciclo de Vida do TDD 
Vermelho 
1. Escreva um 
teste que falhe 
Refatore Verde 
2. Faça 
funcionar 
3. Faça direito
Ciclo de Vida do TDD 
Por que separar? 
Faça direito Faça funcionar 
Refatore Verde
Ciclo de Vida do TDD
Valores do TDD 
• Foco na qualidade 
• Código “documentado” 
• Sem medo de mudanças
Só mais uma coisa...
Dificuldades do TDD 
• Qualidade tem custo 
• Indefinição 
• Design ruim
Desenvolvimento de Software 
Metáforas
Desenvolvimento de Software 
Amador ou Artesão?
Princípios de Design OO 
S.O.L.I.D. 
Single Responsibility Principle 
Open/close principle 
Liskov substitution principle ...
Testando... 1, 2, 3 
Testes unitários 
Testa uma porção individual do 
código, como uma função, 
método ou classe.
Testando... 1, 2, 3 
Asserções 
Verificações de 
pré e pós-condições do teste
Testando... 1, 2, 3 
Objetos Mock 
Objetos usados em testes que 
simulam o funcionamento de 
um objeto real
Testando... 1, 2, 3 
Tipos de teste 
Integração 
Carga 
Estresse 
Desempenho 
Resiliência 
Aceitação 
Cobertura 
Regressão
Ferramentas 
Plataforma Java 
• Teste unitário 
JUnit, TestNG 
• Teste de integração (web) 
Selenium/Web Driver, HtmlUnit,...
Ferramentas 
• Teste de cobertura 
EclEmma 
Plataforma Java
Prática 
Demonstração 
• Testes unitários 
– Calculadora com JUnit 
• Teste web 
– Pesquisa no Google com WebDriver (Inter...
Conclusões 
Test-Driven Development 
• Não é uma solução mágica 
• TDD não é sobre TDD 
• TDD é um exercício diário 
• TDD...
Pratique!
Perguntas? 
Não tenha medo...
Pensando TDD
Pensando TDD
Pensando TDD
Pensando TDD
Pensando TDD
Pensando TDD
Pensando TDD
Próximos SlideShares
Carregando em…5
×

Pensando TDD

773 visualizações

Publicada em

Uma reflexão sobre desenvolvimento de software, qualidade e como o TDD pode nos ajudar a melhorar em tudo isso.

A versão em PPT, que possui comentários adicionais para cada Slide, pode ser baixada no Google Drive: https://drive.google.com/folderview?id=0B4k-4pdeaM58SEpYcHZSbFdoS0E&usp=sharing

Para maiores informações sobre a palaestra, acesse: http://luizricardo.org/2014/10/pensando-tdd/ ‎

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
773
No SlideShare
0
A partir de incorporações
0
Número de incorporações
32
Ações
Compartilhamentos
0
Downloads
16
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Por que você escolheu ser um desenvolvedor de software?
    Eu sei que muita gente louca, como eu, faz isso porque gosta.
  • Mas precisamos pagar as contas. Esperamos ganhar dinheiro, certo?
  • Embora alguns achem que não dá tanto retorno
  • Como faturar mais com software?
  • É preciso vender e agradar os clientes. Como fazer isso?
  • Software de qualidade. Faz exatamente o que o cliente precisa. Apresentar o mínimo de erros.
  • Ele precisa funcionar!
    O problema é que o software possui certas características o tornam inerentemente complexo.
  • Abstrato: ele não pode ser representado de forma visível. É um verdadeiro desafio mapear os requisitos (o que um software deve fazer).
  • Singular: cada software é diferente, se eu pedir para cada pessoa aqui criar uma calculadora, cada um fará algo diferente
  • Mutável: mude 1 bit e não temos mais o mesmo programa.
  • Complexo: Se você simplifica, ele perde suas características. Não dá pra ter tudo na cabeça. Podemos criar modelagens, mas sempre haverá um gap do modelo até o código concreto.
  • Desenvolvedores acham que conseguem pensar em todo o software, são otimistas. Mas quando implementam surgem os problemas.
  • Como fazer software com qualidade? Alguns dizem: "para o software funcionar, basta fazer direito."
    Alguém já fez um programa que funcionou 100% corretamente da primeira vez?
    Como você garante que ele realmente funciona? 
  • Pensando no ciclo tradicional, nós deixamos o teste por último.
  • Mas mudanças acontecem. Imprevistos. Pessoas e negócios mudam.
  • A filosofia ágil: abrace as mudanças.
  • Gráfico do custo da manutenção. Quanto antes o código estiver coreto melhor. Ao testar depois, achamos problemas muito tarde. O custo de correção aumenta com o tempo que o bug está no sistema.
  • Para corrigir um bug no início do desenvolvimento, você simplesmente “pisa” nele.
  • Bugs não corrigidos vão voltar para assombrar você.
  • Como o TDD ajuda em tudo isso?
    Colocamos o teste primeiro. Durante o design de uma funcionalidade, já é definido o comportamento esperado através de testes. Assim o bug tende a ser encontrado logo de início.
  • Convém uma discussão sobre definição de pronto. Quanto podemos dizer que terminados uma funcionalidade?
  • Podemos dizer que terminamos algo quando terminados de codificar? Geralmente a primeira versão do código tem gambiarras.
  • É preciso "limpar" o código (refatorar), removendo duplicidade, trechos desnecessários, simplificando e melhorando o desempenho.
    Mas isso não basta. O que acontece quando o usuário ou testador encontrar um problema? Atraso e custo.
  • Testar é importante. Mas como você faz? Depurando todo o programa? Executando o programa manualmente e olhando o resultado? O que acontece quando algo precisa ser modificado e é necessário retestar tudo de novo?
  • Podemos automatizar os testes. Mas não é suficiente se levarmos horas e dias para conseguir enviar uma nova versão para o cliente. Ainda há riscos de problemas de configuração em "produção". 
  • Automação na entrega (deploy) permite que uma funcionalidade implementada e testada possa ser colocada em produção sem mais atrasos. Mas não adianta entregar para o cliente sem a documentação.
  • Finalmente acrescentamos ainda a documentação. Lembrando que esta é apenas uma das definições de pronto. Cada projeto pode demandar algo diferente.
  • Ciclo de vida do TDD. Vermelho, Verde e Refatore! Esse é o ciclo de cada funcionalidade.
  • Os três passos são conhecidos como o "mantra" do TDD, que se repete até que o software esteja completa.
  • Primeiro você cira um teste e executa. Isso garante que o teste funciona e mostra a luz vermelha.
  • Em seguida, faça o código funcionar, do jeito mais direto, sem inventar. Não é código ruim, precisa ser código que funcione em "produção".
  • Porque separar as duas coisas: fazer simples e refatorar.

  • A primeira resposta: porque os programadores tendem a ignorar a segunda parte. Se já está funcionando, não mexa!
  • Benefícios do TDD: - Foco na qualidade - Documentação do código através dos testes (o que é esperado para cada funcionalidade) - Acaba com o medo de mudanças
  • Você vê um código feito e diz: não mexa, pode parar de funcionar.
    O TDD dá coragem ao desenvolvedor. Permite a melhoria do sistema sem medo de mudar o que está lá, permite que outras pessoas saibam o que o seu código deve fazer. 
    Testes de regressão automatizados podem ser repetidos quantas vezes e quando se desejar. Você não precisa mais refazer todo o teste manualmente.
  • Poréns...
    É preciso investir mais tempo para os testes. Embora na teoria os testes se paguem ao final do projeto, muitos clientes não estão dispostos a pagar por qualidade.
    Indefinição: quando não se consegue saber exatamente quais os requisitos, onde se quer chegar. Como criar testes?
    É necessário ter experiência (prática) e dedicação para conseguir criar bom design do software, além de software testável.
    Os dois primeiros itens são fontes externas de problemas. O ponto que nós, como desenvolvedores precisamos atacar é a questão do projeto do software.
  • Há duas principais metáforas para o que é o desenvolvimento de software. 
    Alguns pensam como Engenheiros de Software, estudando essa disciplina sistematicamente, construindo a "ponte" entre o problema e a solução (próprio software). Eles tentam entender como produzir software "em escala"
    Outros pensam como Artesãos de Software, já que cada software e cada desenvolvedor são únicos. 
  • Ninguém nasce ou mesmo sai de uma faculdade sabendo.
    Algumas pessoas tem jeito, mas aprender a projetar bem exige experiência e disciplina, como os artistas clássicos.
    Para que o TDD funcione bem, o design ou a arquitetura do software conta muito. Ele vai ajudar na disciplina de sempre buscar a perfeição.
  • Os princípios de design orientado a objetos SOLID são:
    Single Responsibility Principle: cada classe deve ter uma responsabilidade única. Ela só vai precisar ser modificada quando houver mudança nos requisitos relacionados a sua função. Open/close principle: as classes devem ser abertas para extensão e fechadas para modificação. Isso significa que novas funcionalidades devem ser adicionadas sem alterar as classes existentes. Isso geralmente é obtido através de herança e polimorfismo. Liskov substitution principle: objetos devem poder ser substituídos por subtipos sem quebrar o programa. Isso significa que que subclasses não podem quebrar o contrato da superclasse que estendem. Interface segregation principle: interfaces específicas são melhores do que uma interface genérica com vários métodos. Dependency inversion principle: uma classe não deve depender de outras classes concretas, mas de abstrações.
    Não entrarei em detalhes, porque seria outra apresentação. Isso é apenas uma informação para o ouvinte buscar e aprender por si mesmo.
  • Se fosse possível resumir tudo isso em algo bem simples: temos que aprender a dividir as funcionalidades do software em componentes que sejam o mais independentes possível.
  • Ao dividir o software em componentes, podemos testá-lo individualmente para garantir que cada unidade funcione como esperado. Isso evita muita dor de cabeça na hora de "juntar tudo".
    Os testes unitários devem evitar interferência (possíveis erros) e outras classes. 
  • É comum iniciarmos testes somente executando código, sem realmente verificar a saída das rotinas. Porém, um teste automatizado somente possui valor real se ele puder por si mesmo determinar o sucesso ou falha.
  • Quanto há dependência de algo, uma saída é usar os mocks, que são objetos que simulam o real. Assim, defini-se o comportamento esperado das dependências de forma que o teste é mais rápido e independente dos outros componentes estarem corretos ou não.
    Muitos argumentam que mocks são um quebra-galho e devem ser evitados. Um sinal de design ruim é justamente a necessidade de muitos mocks, pois significa que há um forte acoplamento entre os componentes.
  • Tipos de teste:
    Integração: teste com que envolve vários componentes do sistema, para ver se a integração ocorre normalmente. Nível um pouco mais alto que o teste unitário.
    Carga: quantos usuários o sistema consegue atender bem (carga máxima).
    Estresse: até quanto o sistema consegue atender, mesmo que mal (sem travar).
    Desempenho: o tempo de resposta até uma certa quantidade de usuários.
    Resiliência: como o sistema se recupera de falhas ou utilização acima do limite (picos).
    Aceitação: o usuário ou interessado verifica se o software faz o que foi pedido.
    Cobertura: quais partes do código foram realmente testadas?
    Regressão: repetição dos testes já executados para garantir que não houve regressão (algo parou de funcionar). Aqui o TDD com testes automatizados realmente brilha.
  • Ferramentas de automação de testes em Java:
    - http://junit.org/
    - http://testng.org/doc/index.html
    - http://www.seleniumhq.org/
    - http://htmlunit.sourceforge.net/ 
    - http://www8.hp.com/us/en/software-solutions/unified-functional-testing-automation/ (fechado)
    - https://github.com/mockito/mockito 
    - http://jmock.org/
    - https://code.google.com/p/powermock/
    - http://easymock.org/ 
    Com exceção do UFT (Unified Functional Testing) da HP, todos os demais são de código-aberto e gratuitos.
  • Ferramentas de automação de testes em Java:
    - http://www.eclemma.org/
  • Ferramentas de automação de testes em Java:
    - http://www.eclemma.org/
  • TDD não é uma solução mágica. Você deve experimentar e chegar à conclusão do que funciona, quando funciona e onde funciona.
    TDD is not about TDD. Todo processo seguido pelo processo, cegamente, mais atrapalha do que ajuda. 
    É um exercício diário para você. Qualidade em software é algo que exige dedicação, experiência e disciplina. 
    TDD é sobre como criar software de qualidade, que faz o que precisa fazer, seja entregue no tempo, e não seja um pesadelo para o programador. Ele tenta dar uma direção a ser seguida.
    É preciso se aplicar e aperfeiçoar esses princípios que apenas começamos a ver. 

  • Como fazer uma obra-prima ao invés de arte moderna? Como fazer um prédio que não cai?Pratique, só assim se alcança qualidade.
  • Pensando TDD

    1. 1. Pensando TDD 08/10/2014
    2. 2. Direitos Autorais Você está autorizado e incentivado a distribuir este material. Copie, compartilhe e modifique, apenas cite a fonte.
    3. 3. Autoria Luiz Ricardo luizricardo.org facebook.com/StateOfTheArtBlog
    4. 4. Código-fonte O código dos exemplos práticos pode ser obtido no link: https://github.com/utluiz/tdd-example
    5. 5. Porque software?
    6. 6. $$$???
    7. 7. Software de Qualidade Faz o que deveria fazer SEM ERROS
    8. 8. Software de Qualidade Funciona
    9. 9. Dificuldades do Software Abstrato Sem representação visível Dificuldade em identificar requisitos
    10. 10. Dificuldades do Software Singular Cada um é diferente
    11. 11. Dificuldades do Software Mutável 1 bit muda tudo
    12. 12. Dificuldades do Software Complexo Simplificação Perda de informação
    13. 13. Expectativa Realidade
    14. 14. Como fazer software de qualidade?
    15. 15. Teste Teste Teste Teste Teste
    16. 16. TDD Test-Driven Development Metodologia ágil de desenvolvimento de software cujo objetivo é gerar código limpo que funciona
    17. 17. Fases do Desenvolvimento Tradicional Projeto Implementação Teste
    18. 18. Mudanças acontecem...
    19. 19. Correção de Bugs Custo por fase Design Implementação Teste Manutenção
    20. 20. Fases do Desenvolvimento TDD Projeto/Teste Implementação
    21. 21. Definição de “Pronto” Quando terminamos uma nova funcionalidade?
    22. 22. Definição de “Pronto” Código
    23. 23. Definição de “Pronto” Código limpo
    24. 24. Definição de “Pronto” Código limpo Testado
    25. 25. Definição de “Pronto” Código limpo Teste automatizado
    26. 26. Definição de “Pronto” Código limpo Teste automatizado Deploy automatizado
    27. 27. Definição de “Pronto” Código limpo Teste automatizado Deploy automatizado Documentado
    28. 28. Ciclo de Vida do TDD Vermelho Refatore Verde
    29. 29. Ciclo de Vida do TDD O “Mantra” Vermelho, verde, refatore Vermelho, verde, refatore Vermelho, verde, refatore Vermelho, verde, refatore ...
    30. 30. Ciclo de Vida do TDD Vermelho 1. Escreva um teste que falhe Refatore Verde
    31. 31. Ciclo de Vida do TDD Vermelho 1. Escreva um teste que falhe Refatore Verde 2. Faça funcionar
    32. 32. Ciclo de Vida do TDD Vermelho 1. Escreva um teste que falhe Refatore Verde 2. Faça funcionar 3. Faça direito
    33. 33. Ciclo de Vida do TDD Por que separar? Faça direito Faça funcionar Refatore Verde
    34. 34. Ciclo de Vida do TDD
    35. 35. Valores do TDD • Foco na qualidade • Código “documentado” • Sem medo de mudanças
    36. 36. Só mais uma coisa...
    37. 37. Dificuldades do TDD • Qualidade tem custo • Indefinição • Design ruim
    38. 38. Desenvolvimento de Software Metáforas
    39. 39. Desenvolvimento de Software Amador ou Artesão?
    40. 40. Princípios de Design OO S.O.L.I.D. Single Responsibility Principle Open/close principle Liskov substitution principle Interface segregation principle Dependency inversion principle
    41. 41. Testando... 1, 2, 3 Testes unitários Testa uma porção individual do código, como uma função, método ou classe.
    42. 42. Testando... 1, 2, 3 Asserções Verificações de pré e pós-condições do teste
    43. 43. Testando... 1, 2, 3 Objetos Mock Objetos usados em testes que simulam o funcionamento de um objeto real
    44. 44. Testando... 1, 2, 3 Tipos de teste Integração Carga Estresse Desempenho Resiliência Aceitação Cobertura Regressão
    45. 45. Ferramentas Plataforma Java • Teste unitário JUnit, TestNG • Teste de integração (web) Selenium/Web Driver, HtmlUnit, UFT/QTP • Mocks Mockito, JMock, PowerMock, EasyMock
    46. 46. Ferramentas • Teste de cobertura EclEmma Plataforma Java
    47. 47. Prática Demonstração • Testes unitários – Calculadora com JUnit • Teste web – Pesquisa no Google com WebDriver (Internet) – Navegação entre duas páginas
    48. 48. Conclusões Test-Driven Development • Não é uma solução mágica • TDD não é sobre TDD • TDD é um exercício diário • TDD é disciplina
    49. 49. Pratique!
    50. 50. Perguntas? Não tenha medo...

    ×