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.
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..
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.
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
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
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