O documento discute a prática de TDD (Test-Driven Development) como uma ferramenta para melhorar a arquitetura de software, enfatizando que testes devem ser escritos antes do código. Também aborda a relação entre TDD, qualidade de design e a necessidade de um planejamento arquitetônico. Apesar das críticas ao TDD, a prática é defendida como uma forma de identificar problemas de design e garantir uma melhor manutenção do código.

1. MANDIC + RIVENDEL.
ESPECIALISTAS EM CLOUDS.
TDD como ferramenta de
arquitetura

2. Desenvolvedor
everton.tavares@rivendel.com.br
@ezidio
mandic.com.br
Everton Tavares

3. #EspecialistaFaz

4. DevParaná
http://slack.devparana.org

5. O que é TDD?

6. 6
TDD tem uma fórmula
simples:
Escreva os testes antes
do código de
produção.

7. 7
Mantra do TDD

8. Code that's hard to test in
isolation is poorly designed

9. 9
O que é um código
bem projetado?

10. 10
Alta coesão, baixo
acoplamento, design
Patterns, DRY, SOLID,
etc...

11. 11
Alta cobertura de
testes ajuda a
refatorar para padrões
sem medo.

12. TDD garante uma arquitetura de
qualidade?

13. 13
O que é uma boa
arquitetura?

14. 14
MVC, MVVM,
Hexagonal, CQRS,
Onion, DDD, Clean
Architecture

15. 15
Qual arquitetura é melhor?

16. 16
Não é o TDD que
garante a arquitetura.
Ela deve ser
planejada...

17. 17

18. TDD “prejudica” o design da
aplicação? ...

19. 19
TDD is dead. Long live testing.
DAVID HEINEMEIER HANSSON (DHH)
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-
live-testing.html

20. 20
user = User.find_by(name: 'David')
user.name = 'Dave'
user.save

21. 21
O nível de abstração e
desacoplamento
depende do contexto
da aplicação.

22. Quanto mais testes, mais difícil
de manter o código?

23. 23
Qual arquitetura é mais fácil de manter?

24. 24
Agora troque “User” por “Test”

25. 25
Testes também devem
ser arquitetados.

26. Como TDD ajuda na arquitetura?

27. 27
TDD é uma ferramenta
que ajuda identificar
“smells” no design.

28. 28
Como?

29. 29
Dificuldade em
escrever testes

30. 30
Excesso de testes em
uma única unidade.

31. 31
Testes inteligentes

32. 32
Excesso de validações
(asserts)

33. 33
Efeito cascata em
testes não
relacionados.

34. 34
Mas para tudo isso,
deve-se saber
implementar testes!

35. Code that's hard to test in
isolation is poorly designed?

36. 36
Nem sempre...
Você pode estar
fazendo da forma
errada!

37. Perguntas?

38. Obrigado!