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.

1. Francisco Clauvane

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