Test-Driven Development - Introdução

1,099 views
1,006 views

Published on

Palestra com foco na introdução ao desenvolvimento orientado à testes, passando em temas como: Design OO; Domain-Driven Design; Modelo Anêmico; Refabricação do código legado; Design Patterns; Princípios OO e boas práticas.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,099
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
10
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Test-Driven Development - Introdução

  1. 1. Test-Driven Development hlegius
  2. 2. Test-Driven Development TD.. o quê ?
  3. 3. Era uma vez…
  4. 4. Barbie Software Engineer
  5. 5. Era uma vez… Barbie Software Engineer
  6. 6. Era uma vez… Barbie Software Engineer executa
  7. 7. Era uma vez… Barbie Software Engineer SVN versiona
  8. 8. Várias Barbie’s Software Engineer
  9. 9. Várias Barbie’s Software Engineer Modificando a aplicação sem garantias !
  10. 10. Um bug. Resultados…
  11. 11. … e outro. Resultados…
  12. 12. … e mais um. Resultados…
  13. 13. … outro, outro e tantos outros… Resultados…
  14. 14. Desenvolvimento orientado à testes
  15. 15. Testa Publica Codifica Forma non-TDD Desenvolvimento orientado à testes
  16. 16. Desenvolvimento orientado à testes Testa Publica Codifica Forma non-TDD Escreve o teste Cria a implementação Valida a implementação Incrementa o teste Evolui o design da implementação A maneira focada em testes
  17. 17. Mas afinal, qual o objetivo do TDD ?
  18. 18. Mas afinal, qual o objetivo do TDD ? Mitigar bugs ?
  19. 19. Mas afinal, qual o objetivo do TDD ? Mitigar bugs ? Evitar re-testes ?
  20. 20. Mas afinal, qual o objetivo do TDD ? Mitigar bugs ? Evitar re-testes ? Evoluir o design ?
  21. 21. Mas afinal, qual o objetivo do TDD ? Mitigar bugs ? Evitar re-testes ? Evoluir o design ? mimimi
  22. 22. Mas afinal, qual o objetivo do TDD ? Mitigar bugs ? Evitar re-testes ? Evoluir o design ? mimimi Validar o escopo ?
  23. 23. Mas antes…
  24. 24. … falando sobre agile O Manifesto Ágil
  25. 25. … falando sobre design Table Module
  26. 26. … falando sobre design Table Module  Fácil para gerar automáticamente;
  27. 27. … falando sobre design Table Module  Fácil para gerar automáticamente;  Fácil para developers com pouca experiência;
  28. 28. … falando sobre design Table Module  Fácil para gerar automáticamente;  Fácil para developers com pouca experiência;  One size fits all;
  29. 29. … falando sobre design Table Module  Fácil para gerar automáticamente;  Fácil para developers com pouca experiência;  One size fits all;  Alto acoplamento; viola o SRP;
  30. 30. … falando sobre design Table Module  Fácil para gerar automáticamente;  Fácil para developers com pouca experiência;  One size fits all;  Alto acoplamento; viola o SRP;  Pouco flexível, e;
  31. 31. … falando sobre design Table Module  Fácil para gerar automáticamente;  Fácil para developers com pouca experiência;  One size fits all;  Alto acoplamento; viola o SRP;  Pouco flexível, e;  Dados e comportamento estão separados. 
  32. 32. … falando sobre design Table Module Mais do mesmo: Transaction Script e Service Layer @ PoEAA por Fowler Domain Model
  33. 33. … falando sobre princípios S O L I D
  34. 34. … falando sobre princípios S O L I D ingle Responsibility Principle
  35. 35. … falando sobre princípios S O L I D pen Close Principle ingle Responsibility Principle
  36. 36. … falando sobre princípios S O L I D pen Close Principle ingle Responsibility Principle iskov Substitution Principle
  37. 37. … falando sobre princípios S O L I D pen Close Principle ingle Responsibility Principle iskov Substitution Principle nterface Segregation Principle
  38. 38. … falando sobre princípios S O L I D pen Close Principle ingle Responsibility Principle iskov Substitution Principle nterface Segregation Principle ependency Inversion Principle
  39. 39. E agora ele, o TDD.
  40. 40. Test-Driven Development
  41. 41. Test-Driven Development Specification-Driven Design Soa bem melhor e é menos confuso. 
  42. 42. Test-Driven Development • Focado na especificação; • Evolução contínua, e; • Documentação executável; • Three-one Tem como objetivos:
  43. 43. Test-Driven Development • Focado na especificação; • Evolução contínua, e; • Documentação executável; • Three-one • OODesign; • Domain-Driven Design; • Modelo rico; • Integração Contínua, e; • Deploy contínuo. • Three-one Tem como objetivos: Premissa para:
  44. 44. Arquitetura dos Testes
  45. 45. Arquitetura dos testes Escreve o teste Cria a implementação Valida a implementação Incrementa o teste Evolui o design da implementação • Escreve-se o teste com o mínimo possível; • Procure focar-se na especificação; • Não caia na tentação de codificar algo antes; • Verifique se o teste falha sem a implementação, e; • Certifique-se de que o teste está validando o que está no documento de especificação.
  46. 46. Arquitetura dos testes Escreve o teste Cria a implementação Valida a implementação Incrementa o teste Evolui o design da implementação • Implementação coesa, seguindo um design simplista baseado no SOLID, por exemplo; • Não rascunhe. Crie o necessário para aquela implementação, baseado no que leu até o momento, e; • Não rode o teste até ter finalizado.
  47. 47. Arquitetura dos testes Escreve o teste Cria a implementação Valida a implementação Incrementa o teste Evolui o design da implementação • Execute o teste. 
  48. 48. Arquitetura dos testes Escreve o teste Cria a implementação Valida a implementação Incrementa o teste Evolui o design da implementação • Melhore o design do teste.
  49. 49. Arquitetura dos testes Escreve o teste Cria a implementação Valida a implementação Incrementa o teste Evolui o design da implementação • Melhore o design da implementação.
  50. 50. Arquitetura dos testes E o modelo anêmico
  51. 51. Arquitetura dos testes
  52. 52. Arquitetura dos testes • Alto acoplamento; • SRP, e; • Dificulta testes de unidade.
  53. 53. Arquitetura dos testes Design pattern: Service • Alto acoplamento; • SRP, e; • Dificulta testes de unidade.
  54. 54. Arquitetura dos testes
  55. 55. Arquitetura dos testes • Alto acoplamento; • Viola SRP; • Dificulta testes de unidade; • Baixa legibilidade, e; • Orientado à função.
  56. 56. Arquitetura dos testes • Alto acoplamento; • Viola SRP; • Dificulta testes de unidade; • Baixa legibilidade, e; • Orientado à função. Um factory ao init(), melhoraria :)
  57. 57. The root of all evil is
  58. 58. Arquitetura dos testes Ele, o symfony ! Design pattern arquitetônico: Table Module Design pattern estrutural: Row Data Gateway
  59. 59. Arquitetura dos testes • Alto acoplamento; • SRP; • Orientado à “tabelas”; • One size fits all; • Utiliza-se herença à composição, e; • Fácil uso.
  60. 60. Soluções ?
  61. 61. • Mudar a arquitetura, ou; • Redobrar atenção aos princípios SOLID.
  62. 62. Design dos testes
  63. 63. Design dos testes Single Responsibility Principle;
  64. 64. Design dos testes Single Responsibility Principle; Baixo acoplamento
  65. 65. Design dos testes Single Responsibility Principle; Baixo acoplamento; Doc block e annotations na classe
  66. 66. Design dos testes Single Responsibility Principle; Baixo acoplamento; Doc block e annotations na classe; Keep It Simple, Stupid.
  67. 67. Design dos testes WTF !?
  68. 68. Design dos testes Qual o problema aqui ?
  69. 69. Design dos testes
  70. 70. Por fim…
  71. 71. • Entender o que é realmente OO Design;
  72. 72. • Entender o que é realmente OO Design; • Não esquecer dos princípios S.O.L.I.D;
  73. 73. • Entender o que é realmente OO Design; • Não esquecer dos princípios S.O.L.I.D; • #nota TDD é validação de escopo, não bug finder;
  74. 74. • Entender o que é realmente OO Design; • Não esquecer dos princípios S.O.L.I.D; • #nota TDD é validação de escopo, não bug finder; • Arquitetura é importante ! ;
  75. 75. • Entender o que é realmente OO Design; • Não esquecer dos princípios S.O.L.I.D; • #nota TDD é validação de escopo, não bug finder; • Arquitetura é importante ! ; • Design patterns não são balas-de-prata, e;
  76. 76. • Entender o que é realmente OO Design; • Não esquecer dos princípios S.O.L.I.D; • #nota TDD é validação de escopo, não bug finder; • Arquitetura é importante ! ; • Design patterns não são balas-de-prata, e; • Refatore cedo, refatore regularmente *
  77. 77. E para criar testes…
  78. 78. E para criar testes… http://www.phpunit.de ;)
  79. 79. E isto é apenas o começo.

×