A apresentação discute a importância dos testes de unidade e TDD, incluindo como eles melhoram o design de classes, qualidade do código e acoplamento. Também aborda níveis de teste, mock objects e quando não usar TDD.
2. Sobre
Esta apresentacao teve como base o livro de TDD da
casa do codigo, a minha experiencia profissional e as
dicas dadas por profissionais mais experientes. Onde o
objetivo da mesma nao e ensinar como usar o
junit, mas sim, a importancia dos testes, e o que eles
podem agregar de positivo em projetos de software.
3. Sumario
1. Teste de unidade
2. TDD
3. Design de classes
4. Qualidade do codigo
5. Coesao
6. Acoplamento
7. Mock Objects
8. Niveis de teste
9. Quando nao usar TDD
4. 1-Teste de unidade
Os sistemas sao geralmente grandes e complexos
Um teste de unidade nao se preocupa com o sistema
todo, mas sim com um “pedaco” dele.
Geralmente esses pedacos sao classes.
Logo, os teste de unidade serao responsaveis pelas
classes.
5. 2-TDD
Foco no teste e nao na implementacao
Codigo nasce testado
Simplicidade
Melhor reflexao sobre o design de classes
Sem TDD vamos obter o mesmo resultado?
Feedback dos teste
6. 3-Design de classe
Para muitos TDD e um guia para um bom design de
classes
Feedback
“A pratica de TDD nao guia o desenvolvedor para um
bom projeto de classes de forma automatica;A
experiencia e o conhecimento do desenvolvedor sao
fundamentais para criar o software orientado a objeto”
7. 4-Qualidade do codigo
Testes podem apresentar problemas no codigo
Teste deve ser algo facil e produtivo
Todas as boas praticas que o desenvolvedor aplica no
codigo de producao pode ser utilizado no codigo de
teste
8. 5-Coesao
Classes que fazem muita coisas sao dificeis de serem
mantidas
Principio da responsabilidade unica
Uma classe coesa e aquela que possui apenas uma unica
responsabilidade
Em sistemas orientado a objetos a ideia e sempre
buscar classes coesas
Feedback
9. 6-Acoplamento
Dizemos que uma classe esta acoplada a outra quando
existe alguma relacao de dependencia entre elas
Mudanca nesta classes podem impactar negativamente
Inversao de controle e injecao de dependencia
Repassando a dependencia para uma abstracao
Cenario mais preparado para os impactos que as
possiveis mudancas podem causar
Classes altamente coesas e pouco acopladas sao dificeis
de serem projetadas
10. 7-Mock Objects
Em um teste onde existem classes integradas, se o teste falhar
, como saber qual objeto gerou o erro
“Objetos duble”
Objetos que simulam o comportamento de outras
Simula objetos que surgem como dependencia durante os testes
Mocks “escondem” problemas que so seriam vistos em producao
Classes que representam entidades, servicos, utilitarios, ou
qualquer coisa que “encoste” na infraestrutura nao deve ser
mockada
Classes complexas e trabalhosas devem ser mockadas, por
exemplo,classes de infraestrutura
Mockito
11. 8-Niveis de teste
Unidade
Testa modulos( classes ) de forma independente do restante do
sistema
Integracao
Testa os modulos funcionando de forma conjunta
Botton-up
Top-down
Sistema
Testa todo o sistema mas se preocupa apenas com aspecto gerais
Aspectos funcionais
Regra de negocio
nao-funcionais
Expectativa do cliente
12. Fim
Sites e livros recomendados
http://www.guj.com.br
http://www.CasaDoCodigo.com.br
http://www.caelum.com.br/online
https://github.com/clauvane
https://github.com/rponte