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.

1. Test-Driven
Development
hlegius

2. Test-Driven Development
TD.. o quê ?

3. Era uma vez…

4. Barbie
Software Engineer

5. Era uma vez…
Barbie Software Engineer

6. Era uma vez…
Barbie Software Engineer
executa

7. Era uma vez…
Barbie Software Engineer
SVN
versiona

8. Várias Barbie’s Software Engineer

9. Várias Barbie’s Software Engineer
Modificando a aplicação sem garantias !

10. Um bug.
Resultados…

11. … e outro.
Resultados…

12. … e mais um.
Resultados…

13. … outro,
outro e tantos outros…
Resultados…

14. Desenvolvimento orientado à testes

15. Testa
Publica
Codifica
Forma non-TDD
Desenvolvimento orientado à testes

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. Mas afinal, qual o objetivo do TDD ?

18. Mas afinal, qual o objetivo do TDD ?
Mitigar bugs ?

19. Mas afinal, qual o objetivo do TDD ?
Mitigar bugs ?
Evitar
re-testes ?

20. Mas afinal, qual o objetivo do TDD ?
Mitigar bugs ?
Evitar
re-testes ?
Evoluir
o
design ?

21. Mas afinal, qual o objetivo do TDD ?
Mitigar bugs ?
Evitar
re-testes ?
Evoluir
o
design ?
mimimi

22. Mas afinal, qual o objetivo do TDD ?
Mitigar bugs ?
Evitar
re-testes ?
Evoluir
o
design ?
mimimi
Validar
o
escopo ?

23. Mas antes…

24. … falando sobre agile
O Manifesto Ágil

25. … falando sobre design
Table Module

26. … falando sobre design
Table Module
 Fácil para gerar automáticamente;

27. … falando sobre design
Table Module
 Fácil para gerar automáticamente;
 Fácil para developers com pouca
experiência;

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. … 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. … 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. … 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. … falando sobre design
Table Module
Mais do mesmo: Transaction Script e Service Layer @ PoEAA por Fowler
Domain Model

33. … falando sobre princípios
S
O
L
I
D

34. … falando sobre princípios
S
O
L
I
D
ingle Responsibility Principle

35. … falando sobre princípios
S
O
L
I
D
pen Close Principle
ingle Responsibility Principle

36. … falando sobre princípios
S
O
L
I
D
pen Close Principle
ingle Responsibility Principle
iskov Substitution Principle

37. … falando sobre princípios
S
O
L
I
D
pen Close Principle
ingle Responsibility Principle
iskov Substitution Principle
nterface Segregation Principle

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. E agora ele, o TDD.

40. Test-Driven Development

41. Test-Driven Development
Specification-Driven Design
Soa bem melhor e é menos confuso. 

42. Test-Driven Development
• Focado na especificação;
• Evolução contínua, e;
• Documentação executável;
• Three-one
Tem como objetivos:

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. Arquitetura dos Testes

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. 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. 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. 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. 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. Arquitetura dos testes
E o modelo anêmico

51. Arquitetura dos testes

52. Arquitetura dos testes
• Alto acoplamento;
• SRP, e;
• Dificulta testes de unidade.

53. Arquitetura dos testes
Design pattern: Service
• Alto acoplamento;
• SRP, e;
• Dificulta testes de unidade.

54. Arquitetura dos testes

55. Arquitetura dos testes
• Alto acoplamento;
• Viola SRP;
• Dificulta testes de unidade;
• Baixa legibilidade, e;
• Orientado à função.

56. Arquitetura dos testes
• Alto acoplamento;
• Viola SRP;
• Dificulta testes de unidade;
• Baixa legibilidade, e;
• Orientado à função.
Um factory ao init(), melhoraria :)

57. The root of all evil is

58. Arquitetura dos testes
Ele, o symfony !
Design pattern arquitetônico: Table Module
Design pattern estrutural: Row Data Gateway

59. Arquitetura dos testes
• Alto acoplamento;
• SRP;
• Orientado à “tabelas”;
• One size fits all;
• Utiliza-se herença à composição, e;
• Fácil uso.

60. Soluções ?

61. • Mudar a arquitetura, ou;
• Redobrar atenção aos princípios SOLID.

62. Design dos testes

63. Design dos testes
Single Responsibility Principle;

64. Design dos testes
Single Responsibility Principle;
Baixo acoplamento

65. Design dos testes
Single Responsibility Principle;
Baixo acoplamento;
Doc block e annotations na classe

66. Design dos testes
Single Responsibility Principle;
Baixo acoplamento;
Doc block e annotations na classe;
Keep It Simple, Stupid.

67. Design dos testes
WTF !?

68. Design dos testes
Qual o problema aqui ?

69. Design dos testes

70. Por fim…

71. • Entender o que é realmente OO Design;

72. • Entender o que é realmente OO Design;
• Não esquecer dos princípios S.O.L.I.D;

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. • 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. • 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. • 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. E para criar testes…

78. E para criar testes…
http://www.phpunit.de ;)

79. E isto é apenas o
começo.