Qualidade no desenvolvimento de Software com TDD e PHPUnit

2,894 views

Published on

Published in: Technology, Business
1 Comment
7 Likes
Statistics
Notes
No Downloads
Views
Total views
2,894
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
100
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Qualidade no desenvolvimento de Software com TDD e PHPUnit

    1. 1. Qualidade de Softwarecom TDD e PHPUnit Domingos Teruel Desenvolvedor São José, 21 de agosto de 2011
    2. 2. O Palestrante✦ Tecnólogo em Computação especialista em Sistemas Web e Interface✦ Atua na área de desenvolvimento e implementação de projetos de Software Web✦ Desenvolvedor Mobile✦ Desenvolvedor PHP desde 1999 e membro ativo desde 2001✦ Desenvolvedor WordPress✦ Membro ativo das comunidades de SL: PHP-SP, PHP-SC, ZF-BR, KDE-BR, OpenSUSE-BR, AMAROK-DE e WP-DEVEL✦ Trocou São Paulo por Floripa para desenvolver seu trabalho na Primesoft Sistemas✦ Na rede: http://about.me/mingomax
    3. 3. A Audiência✓ Estudantes?✓ Curiosos / Entusiastas?✓ Desenvolvedores PHP?✓ Desenvolvedores de outras linguagens?✓ Todas as opções acima!✓ Nenhuma da Opções acima!
    4. 4. Agenda• Contextualização• TDD• Teste Unitários• PHPUnit
    5. 5. Reflexão
    6. 6. • Errar é inerente a natureza humana. Precaver-se contra os erros é uma atitude inteligente.• O processo de desenvolvimento de software é sujeito a erros. Sendo assim, a atividade de teste é fundamental para se obter produtos de software com garantia de qualidade.• Discordar ou ignorar a frase acima revela grande amadorismo.
    7. 7. Qualidade de Software“Totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas.”
    8. 8. • Conformidade a: • Requisitos funcionais e de desempenho; • Padrões e convenções de desenvolvimento preestabelecidos; • Atributos implícitos que todo software desenvolvido profissionalmente deve possuir.
    9. 9. Como garantir aqualidade de software?• Aplicação de métodos e ferramentas técnicas;• Realização de revisões técnicas e inspeções;• Atividades de testes;• Aplicação de padrões;
    10. 10. Por quê surgem as falhas?• Alterações;• Tempo;• Complexidade;
    11. 11. TESTESPorque você precisa dele, mas ainda não sabe
    12. 12. Prós
    13. 13. • “Simulação” • Facilidade de testar funções sem precisar preencher formulários, criar usuários • Tudo fica centralizado no teste e é feito apenas uma vez• “Certeza” • Testes podem simular todas situações possíveis e garantir que seu código funciona como esperado• “Garantia” • Com um sistema coberto de testes você tem certeza que sua alteração não vai quebrar outra área do sistema
    14. 14. Contras
    15. 15. • Tempo • Embora você gaste mais tempo criando testes, você ganha tempo durante as simulações e na manutenção• Gerência • Convencer os responsáveis pelo projeto de que testes irão trazer lucro é geralmente complicado
    16. 16. O que são testes?
    17. 17. “ O teste consiste em executar o programa com a intenção deencontrar erros”. (Myers, 1979)
    18. 18. • Principais objetivos dos testes: • Foco na prevenção de erros; • Descobrir sintomas causados por erros; • Fornecer diagnósticos claros para que os erros sejam facilmente corrigidos;
    19. 19. Teste versus Depuração
    20. 20. Objetivo do teste: mostrar que o software temerros.Objetivos da depuração: encontrar a causa doerro detectado no teste, e projetar e implementar asmodificações no programa para correção do erro
    21. 21. Tipos de testes
    22. 22. • Testes de Unidade;• Testes de Integração;• Testes de Sistema;• Testes de Integração de Sistema;• Testes de Aceitação;
    23. 23. A “Espiral da Morte” do Teste
    24. 24. Test DrivenDevelopment, TDD
    25. 25. “TDD = Test-First + Design Incremental” Kent Beck
    26. 26. • TDD é uma técnica de desenvolvimento de software cujo processo é formado por pequenas iterações para o desenvolvimento de uma nova funcionalidade, começando pela implementação de um caso de teste, depois pelo código necessário para fazer o teste passar, e finalmente pela refatoração do código visando melhor acomodar as mudanças feitas.• Não é um método para testar software, mas para construir software.• TDD vem do conceito de “test-first programming” do XP (Extreme Programming), mas acabou ganhando tanto interesse, que hoje tem sido adotado independente do XP e das técnicas de programação ágil;
    27. 27. Test-first
    28. 28. • Escrever testes antes da implementação: • Faz você pensar no comportamento • Reduz código especulativo • Documenta
    29. 29. • 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
    30. 30. Design incremtal
    31. 31. • Adição de novas funcionalidades em pequenos passos• O conceito chave de TDD é ter um feedback rápido das mudanças no código
    32. 32. • A Metodologia TDD é conduzida através dos “testes do programador”.• Frequentemente esses testes são chamados de “teste de unidade”, mas esse nem sempre é o caso (pode ser teste de integração).• É importante destacar que não se trata dos testes de sistema (caixa preta) nem os de aceitação (feitos pelo usuário final)
    33. 33. MANTRA DO TDD
    34. 34. Ainda sobre tipo de testes
    35. 35. Testes Unitários
    36. 36. • Testam apenas um componente do sistema• Todos os outros componentes são simulados (mock objects)• Ferramenta: PHPUnit• Fundamental para a prática do TDD!
    37. 37. Testes de Integração
    38. 38. • Testam a integração entre componentes• Envolvem dois ou mais componentes (classes+SGBD, classes+SGBD+Fast, etc.)• Ferramenta: PHPUnit, DBUnit, HSQLDB, Fit• Normalmente não utilizado em TDD
    39. 39. Testes de Aceitação
    40. 40. • Testam uma história, funcionalidade ou caso de uso• Envolvem vários componentes do sistema• Ferramenta: PHPUnit, Selenium• Pode ser utilizado em TDD
    41. 41. Teste Unitário e PHPUnit
    42. 42. Atitude!• Testar é uma atividade destrutiva!• Pense de forma negativa quando estiver criando planos de teste ou explorando o software!• Explore funcionalidades, pense no que não foi pensado!
    43. 43. Princípios• São independentes: • Do código já testado; • Da ordem de execução; • Do ambiente;• Devem ser: • Fáceis de escrever; • Fáceis de executar; • Fáceis de compreender; • Desenvolvidos paralelamente ao código;
    44. 44. PHPUnit• Escrito por Sebastian Bergmann• Baseado nos conceitos do JUnit• Atualmente na versão 3.6.12• Requer PHP 5
    45. 45. Escrevendo testesQuando você começar, nunca mais vai parar
    46. 46. Anatomia• Toda classe deve ter seu par para Teste: • nomeClasse.php • <nomeClasse>Test.php• Escrever o caso de teste, usando o pós-fixo “Test” • A classe tem um metodo algumaCoisa() • Deve-se criar um metodo testAlgumaCoisa()
    47. 47. Anatomia de um teste unitário
    48. 48. Raio-x Suite de Testes
    49. 49. Executando
    50. 50. Isolamento• Mantenha seus testes isolados• Nunca rode testes no servidor de produção!• Soluções • Crie uma base separada • Use pastas separadas para arquivos • Sempre destrua tudo que seu teste construiu
    51. 51. Mantenha seu ambiente limpo!
    52. 52. O que não se pode testar?
    53. 53. • Singletons • MinhaClasse::getInstance();• Depêndencias • SO exec(ls -la) • Recursos externos: APIs, Filesystem• Métodos privados • private method fazTudo() {...
    54. 54. Outros recursos interessantes
    55. 55. As vezes os testes precisam de dublês• Dummy• Fake• Stub• Spy• Mock
    56. 56. • Gera resultados não determinísticos (hora, temperatura atual...);• Tem estados que são difíceis de criar ou reproduzir (erro de comunicação da rede);• É lento (um banco de dados completo que precisa ser inicializado antes do teste);• Ainda não existe ou pode ter comportamento alterado;• Teriam que adicionar informações e métodos exclusivamente para os testes (e não para sua função real).
    57. 57. Conclusões
    58. 58. • 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
    59. 59. • 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!
    60. 60. Referências
    61. 61. • 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/• Test-drivendevelopment: by example [KentBeck]• Growing Object-Oriented Software,Guided byTests [Steve Freeman]• PHPUnit Pocket guide [Sebastian Bergmann]
    62. 62. Perguntas
    63. 63. Obrigado!!!!!Feedbacks: http://joind.in/event/view/779

    ×