Test-Driven DevelopmentFrancisco Clauvane

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

Sumario1. Teste de unidade2. TDD3. Design de classes4. Qualidade do codigo5. Coesao6. Acoplamento7. Mock Objects8. Niveis de teste9. Quando nao usar TDD

1-Teste de unidadeOs sistemas sao geralmente grandes e

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

2-TDDFoco no teste e nao na implementacaoCodigo nasce testadoSimplicidadeMelhor reflexao sobre o design de classesSem TDD vamos obter o mesmo resultado?

Feedback dos teste

3-Design de classePara muitos TDD e um guia para um bom

design de classesFeedback

“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”

4-Qualidade do codigoTestes podem apresentar problemas no

codigoTeste deve ser algo facil e produtivoTodas as boas praticas que o desenvolvedor

aplica no codigo de producao pode ser utilizado no codigo de teste

5-CoesaoClasses que fazem muita coisas sao dificeis

de serem mantidasPrincipio 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 coesasFeedback

6-AcoplamentoDizemos que uma classe esta acoplada a

outra quando existe alguma relacao de dependencia entre elasMudanca nesta classes podem impactar

negativamenteInversao de controle e injecao de

dependenciaRepassando a dependencia para uma abstracaoCenario mais preparado para os impactos que

as possiveis mudancas podem causarClasses altamente coesas e pouco acopladas

sao dificeis de serem projetadas

7-Mock ObjectsEm 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 outrasSimula objetos que surgem como dependencia durante os

testesMocks “escondem” problemas que so seriam vistos em

producaoClasses 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

8-Niveis de testeUnidade

Testa modulos( classes ) de forma independente do restante do sistema

IntegracaoTesta os modulos funcionando de forma conjuntaBotton-upTop-down

SistemaTesta todo o sistema mas se preocupa apenas com aspecto

gerais Aspectos funcionais

Regra de negocionao-funcionais

Expectativa do cliente

FimSites e livros recomendados

http://www.guj.com.brhttp://www.CasaDoCodigo.com.brhttp://www.caelum.com.br/onlinehttps://github.com/clauvanehttps://github.com/rponte