1. TDD
A influência do Test-Driven Design no
projeto de classes e no design em
sistemas orientados a objetos

5. Big Design Upfront
Waterfall

6. Grupo de Pessoas

7. Grupo de Pessoas
DiscutamHipóteses

8. DiscutamHipóteses
Design!!
!
Grupo de Pessoas

9. “Não existem requisitos de
software, mas sim hipóteses.”

12. Agile
Triangle

13. Agile
Responder rapidamente ao negóc
Entrega
sustentável
Last Responsible Moment

14. Tempo
Contexto
Quando voce
Supostamente
Deveria tomar
Uma decisão
Quanto mais
Você aguardar
Melhor a decisão
Last Responsible Moment

15. Equilíbrio

16. Equilíbrio
Lean
Gerar valor
Engenharia de Software Ágil

18. Waterfall BDUF Agile
Go Horse
Process
Espectro do Design

19. “ Vamos deixar desse jeito
que funciona, depois
refatoramos e a estrutura
e os patterns emergirão.”
Go Horse Proces

20. Dívida Técnica
- Eder Ignatowicz

21. Software
Apodrece
…
- Eder Ignatowicz

22. “ Se você desenvolve iterativamente e
não aplica práticas de engenharia ágil
sua base de código morrerá em 2 ou 3
anos...
Não se preocupar com o design
em um processo iterativo torna o
projeto insustentável”
James Shore

23. Tempo
CustodeMudança
Designpronto
Manutenção
MurodaImpossibilidadedeManutenção

24. Waterfall BUFD Agile
Go Horse
Process
Espectro do Design
Evolutionary
Design

25. Evolutionary
Design

26. Evolutionary
Design
Refactoring
Continuous Integration
Testing

27. Software Testing

28. Software Testing
Refactoring
Decrease ErrorsLow Coupling
Cohesiveness
Knowledge of bussiness
Trust code

30. TDD!!! <3

31. If you can’t write a test for what you
are about to code, then you shouldn't
even be thinking about coding
- Chaplin 2001

32. A GOOD TEST, IS A FAIL TEST !!!

33. MicroTesting

35. Cenário
Ação
Validar
+
+

36. Teste

37. Teste
Código

38. JUnit

39. Red bar

40. Talk is cheap!
Shut up and show me
the code !

41. Meu Deus, que coisa mais chata e ainda
dá mais trabalho. Pra quê eu vou criar
uma nova classe com métodos, se eu
poderia fazer um método único main,
com todos os possíveis erros e ver no
console o resultado com
System.out.println!?”..
“

42. O Que Testar ?

43. I get paid for code that works, not for tests,
so my philosophy is to test as little as possible
to reach a given level of confidence
(I suspect this level of confidence is high
compared to industry standards, but that
could just be hubris). If I don't typically make
a kind of mistake (like setting the wrong
variables in a constructor), I don't test for it.
I do tend to make sense of test errors, so I'm
extra careful when I have logic with
complicated conditionals. When coding on
a team, I modify my strategy to carefully test
code that we, collectively, tend to get wrong.

44. Your micro
tests TALKS !

45. Design bad smells
on unit tests….

46. Você quer testar um
método privado.

47. Talvez sua classe
tenha muitas
responsabilidades

48. Uma mudança no
código quebra
Muitos testes.

49. Violação do
Open/Close Principle

50. Instanciar uma classe
20 vezes

51. Alto Acoplamento

52. Testar é complicado
por causa do
framework X

53. Baixa separação da
Lógica quanto ao
Dominio

54. Você quer utilizar um
framework de Mock

55. Lei de Deméter

56. Difícil mockar
uma classe.

57. Fraca Abstração

58. Dificil chamar um
método ou instancia
uma classe.

59. Muitas responsabilidades

60. Muitos Assets

61. Violação do Single
Responsibility Principle

62. Code == Design

65. Domain Driven
Design

66. Refactoring is not the same activity as
redesign, where the programmers take a
conscious decision to change a large-
scale structure. That said,having taken a
redesign decision, a team can use a
refactoring techniques to get to new
design incrementally and safely.
”
“
- Growing Object Oriented
Software Guided By Tests

67. Things like TDD and Continuous
Integration have fundamentally
changed the safety in development.
”
“
- Joshua Kerievsky

68. Como praticar Design evolutivo ?
Como criar sistemas resitentes a mudanças
Como criar sistemas capazes de acomodar
constantes e continuas mudanças?
Como prover crecimento sustentável ?

69. Equilíbrio
Refactoring
Gerar valor
Testing/CI

70. +
Cultura de Aprendizado Colaborativo

71. Supere seus limites

72. Conviva com os melhores

73. Apêndices

74. http://crowdtest.me/10-falhas-software-
marcaram-historia/
http://agilealliance.org
http://agilemanifesto.org
http://infoq.com
Lei de Deméter
SOLID Design Principles

75. Referências
http://www.agiledata.org/essays/tdd.html
http://blog.thiagobelem.net/aprendendo-tdd-ou-
desenvolvimento-orientado-a-testes/
http://www.slideshare.net/denisnferrari/tdd-completo
http://www.infoq.com/br/presentations/design-software-morreu
http://www.infoq.com/br/articles/relacao-tdd-qualidade
http://www.infoq.com/br/articles/levison-TDD-adoption-strategy
http://www.infoq.com/br/news/2010/08/por-onde-comecar-
meus-testes

76. toni_esteves
 Software Craftsman;
 Web Developer TRE-AL;
 Graduando Sistemas de Informação;
I am a…