Um bate-papo sobre TDD

Notes de l'éditeur

3. quem aqui faz tdd? quem aqui nao faz tdd?
4. pratica de desenvolvimento de software popularizada pelo kent beck em 2001 a mecânica é simples: você deve escrever um teste antes de escrever o código de produção
5. muitas! diferentes perspectivas
6. testes automatizados são bons! queremos isso!
7. refatorar com testes automatizados é muito fácil e seguro! medo ao refatorar sem isso!
8. tem teste no nome... muitas definições confusas...
9. provando por teoria dos conjuntos.. eles não tem nada em comum a não ser os testes de unidade! nenhum livro de TDD fala sobre elas! - vc pensa em muitas outras coisas quando quer testar!
11. isso mesmo! parece maluquisse?
12. e pensar eh bom! :)
13. só de escrever três linhas de código, eu penso sobre um monte de coisa...
14. o teste é o primeiro cliente - muitas vezes você está mudando um código que nem existe ainda!
15. TDD é uma das práticas que te dão feedback mais rápido sobre o seu código! - só perde pra programação pareada!!
16. TDD diz explicitamente que você deve fazer sempre o mais simples possível. Se seguirmos isso, teremos código simples, que é legal! :)
17. o que vocês gostariam de por numa classe dessa?
18. grande parte da simplicidade eh baseado nisso! chega de adivinhação! o programador só escreve o que realmente precisa!
19. mas daqui a pouco eu critico a maneira que as pessoas entendem isso!
20. claro que não né! nao existe bala de prata!
21. tdd não vai resolver seus problemas de design!
22. - vai escrever um código que seja fácil de testar... - existe uma sintonia muito grande entre código fácil de testar, e código de alta qualidade
23. pq isso acontece? pq você começa a receber as dependências da classe, geralmente pelo construtor! se vc não faz isso, você não consegue testar! - uncle bob diz que gerenciar dependencias eh a parte mais complicada do desenv de sw
24. você escreve classes mais fáceis de serem usadas.. os comportamentos são mais fáceis de serem invocados, você não quer perder tempo configurando o objeto pra usar e etc!
25. se você pergunta pra todo mundo qual a vantagem de TDD, todo mundo diz: é receber as dependências pelo construtor! agora fica fácil injetar qualquer coisa lá!
27. ele evidencia os problemas do seu design
28. eh você, programador, que resolve o problema!
29. se você conseguir ver o problema, já é meio caminho andado!! ver é a parte mais difícil !
30. a maioria deles você percebe basicamente quando está difícil testar! eu, preguicoso, nao quero escrever muito código no meu teste, nao quero pensar muito ali... se eu tenho que pensar muito, algo tá errado!
31. uma God Class é uma classe que é acoplada com outras 20 classes... ela conhece um monte de classes, geralmente coordena trabalhos, mas não tem inteligência nenhuma...
32. explica o código
33. veja que a classe CounterPartyFinder é usada apenas pela MessageUnpacker... Pq não passar a dependência pra ela?
34. Agora podemos ver que essa regra de negócio pode ser encapsulada dentro de outro objeto menor e mais específico, com um nome que faça sentido ao domínio...
35. yay!
36. TDD tem tudo a ver com dependências! eu jah falei que ajuda a pensar melhor nelas? pois é...
37. softwares de gente grande são gigantes e vai ser inevitável acoplar classe com classe... a diferença é que TDD faz com que você acople de uma maneira diferente..
38. classes estaveis sao classes que tem menos chance de mudar! imagina uma interface com 10 classes que a implementa? você nunca vai mudá-la, certo? agora imagina depender de uma classe chamada DriverDaEpson? a chance de mudar é grande, concorda? Porque você não liga de acoplar com IList?
39. logo, queremos acoplar com classes mais estáveis do que a classe cliente. Devemos ir sempre em direção à estabilidade. TDD ajuda nisso, já que você pensa melhor na interface que você precisa depender, e isso geralmente produz interfaces/classes mais estáveis.
40. você começa a observar diferentes tipos de dependências - dependencies, notifications e adjustments
41. dependencies você deve tomar cuidado! elas são imprescindiveis pro seu sistema! então tente ao maximo acoplar com classes estáveis! - notifications de alguma forma podem ser removidas do código, e extraídas, como no exemplo...
42. parecem notifiers, não?
43. lembra do SRP?
44. refatorado para observer... agora quem quiser ser notificado sobre a geracao da nota, torna-se um observer, e será notificado assim que a nota for gerada... isso desacopla o GeradorDeNotaFiscal do resto do processo, e permite que evolua de maneira mais fácil!
45. se vc sente necessidade de testar um método privado, é pq provavelmente essa classe não está coesa! ela tem coisa demais, e vc sente necessidade de testar essas responsabilidades separadas.
46. você começa a extrair esses comportamentos e colocar em classes menores e mais coesas!!
47. é mais fácil compor comportamentos do que criar uma classe com todos os comportamentos
48. imagina agora para escrever todos os testes.. era complicado! precisávamos extrair o comportamento para algum lugar... - outro exemplo: criar filtros... se tal campo foi postado, então adicione isso na condição, e por aí vai...
49. a primeira refatoracao eh levar cada filtro para uma classe especifica (depois pode ter uma factory para montar os filtros)... veja que ficou facil customizar o comportamento de um filtro, além de ser muito mais fácil testar: agora o número de combinações para cada um deles é muito menor!
50. classes pequenas sao mais simples!
51. a ideia é dar passos de bebê em direção à solução mais simples
52. - a ideia de ficar retornando constantes e acrescentando um monte de if é besteira! - o proprio kent beck diz que nao faz assim
53. - o objetivo principal é a solução mais simples e não a mudança mais simples!
54. implementação você refatora mais fácil ! design é difícil refatorar! - ao implementar uma funcionalidade, você deve refatorar o código (e o design) para permitir que essa funcionalidade seja adicionada da maneira mais fácil possível.
55. - acoplamento muito forte - nao dá pra substituir sem mágica! - quero evoluir sem precisar mexer em código que já existe (OCP)
56. - deve-se tomar cuidado para não deixar o conceito vazar da classe
57. veja a API do asp.net mvc! Precisa mockar muita coisa para testar o HttpRequest
58. - deve-se pensar na melhor abstração - lei de demeter
59. - Tell, Don’t Ask
60. ajuda a entender o requisito melhor, e isso gera código mais perto do domínio - levantado como uma das partes mais benéficas do processo pelas pessoas no encontro ágil
61. classes que você não consegue dar um bom nome tem algo errado... talvez o conceito não esteja muito claro!
62. ouça eles! eles tem muito a dizer!