O documento apresenta os principais pontos sobre arquitetura de software testável. Discute o que é arquitetura testável, tipos de testes, TDD (desenvolvimento guiado por testes), a pirâmide de automação de testes e porque devemos adotar essas práticas.

1. Criando Arquitetura
Testável
Do Back ao Front
Cleiton Felipe de Moraes

2. AGENDA
• QUEM SOU EU?
• O QUE É UMA ARQUITETURATESTÁVEL?
• TIPOS DETESTES
• TDD (TEST DRIVEN DEVELOPMENT)
• PIRÂMIDE DE AUTOMAÇÃO DETESTES
• PORQUE DEVEMOS FAZER ISSO?

3. Quem sou eu
• Cleiton Felipe de Moraes
• Software Engineer na GFT
• +|- 10 anos de experiência em
desenvolvimento de software
• Sou um pai do Pedro (anjo azul),
casado, sorocabano que mora em
Curitiba e torce para o Cruzeiro
• Sou nerd e já fui graffiteiro e
skatista...
• Trabalho com desenvolvimento
desde 2009 e já trabalhei com
várias tecnologias como Java, PHP,
ASP Clássico e hoje sou focado na
plataforma .Net
(Web/Desktop/Mobile/Server) e
Azure e estudando GCP e AWS..

4. O que é uma
arquitetura
testável?

5. S O
L I
D
T
DD
B D D
SOFTWARE
O
O
P

6. TIPOS DETESTES...
 Testes de Unidade
 Testes de
Integração
 Testes de
componentes
 Testes de Serviços
 Testes de
Interfaces
Teste Funcional
Teste de Aceitação
SmokeTests
Teste Exploratório
Testes de
Automatizados
Testes Semi-
Automatizados
Testes Manuais

7. TDD (Test Driven-Development)
TDD é o acrônimo deTest Driven-Development ou em português Desenvolvimento guiado pelos
testes.
Em um resumoTDD é o modelo de desenvolvimento onde primeiramente escrevemos os testes
antes mesmo de desenvolvermos a funcionalidade que vai ser testada.
Hã?

8. TDD (Test Driven-Development)
• Confuso neh?
• Vamos melhor isso....
• TDD é uma técnica de desenvolvimento onde constantemente verificamos e validamos
cada função, método ou parte do sistema que estamos fazendo, focando principalmente
em implementar cada funcionalidade com mais coesão e menos complexidade.
• Escrevemos um “teste” bem coeso e direto e implementamos a funcionalidade para
atender aquele teste.

9. TDD (Test Driven-Development)
• O fluxo doTDD segue o principio de Red-Green-Refactor
• Baby-Steps

10. TDD (Test Driven-Development)
• Funcionalidades fazendo aquilo que realmente ela deve fazer.
• Principio SOLID e OOP bem aplicados.
• Se enquadra muito bem com DevOps
• Desenvolvedores entendendo melhor o negócio
• Menor numero de bugs
• Menos vai e volta de tarefas
• Menor custo
• Mais qualidade nas entregas

11. MitosTDD
• Dobro de esforço
• Desenvolvimento mais lento
• Impossível escrever testes
sem saber o design da
aplicação
• Escrever toda a suíte de teste
antes de começar a codificar

12. PIRÂMIDE DE AUTOMAÇÃO DETESTES
UITEST
Service/Acceptance
Test
UnitTests
ManualTest

13. UITEST
Service/Acceptance
Test
UnitTests
ManualTest
Custo
Numerodetestes

14. UnitTest
 Verifica a unidade
 Dependências mockadas
 Testes isolados

15. ServiceTest
 Verifica a funcionalidade
 Cobertura dos serviços
 Testado isoladamente

16. UITest
 Verifica toda a funcionalidade
 Alto custo
 Fácil de quebrar
 Dever ser mínimo

17. ManualTest
 Testado a mão
 Muito caro
 Usar aonde achar apropriado
 Dever ser mínimo

18. AcceptanceTest
 Verifica a funcionalidade
 Usa a linguagem de negócio
 Critérios para completude
 Todos os testes são problematicos

19. Demo

20. Porque devemos fazer isso?
 Prós
 Fácil deTestar
 Melhora o design
 Elimina os medos
 Contras
 TDD requer disciplina
 Maior custo inicial
 O time precisa comprar a
ideia

21. Dúvidas

22. Referências
• Test-Driven Development (Maurício Aniche – Casa do
Código)
• Test-Driven Development by Example – Kent Beck
• Site do Martin Fowler (https://martinfowler.com/)
• Site do Robert C.Martin “Uncle Bob”
(https://blog.cleancoder.com/)
• E muito mais...
• Pluralsight: CursoClean Architecture – Principle and
Practices

23. Contato
Cleiton Felipe de Moraes
Software Engineer
Cleiton.De-Moraes@gft.com
Omehe.Cleiton@Hotmail.com
https://github.com/cleitonfelipe /
https://medium.com/@cleiton_felipe