Test-driven development & Mocking

Test-drivendevelopment&Mocking

Por que utilizar?
Faz você pensar sobre o comportamento requisitado
Reduz o código “especulativo”
Provê uma documentação interna
Melhora na qualidade

Alguns equívocos
Escrever testes após o código de produção é a mesma coisa
TDD é sobre testes
TDD não é útil para o desing de software
Torna lento o desenvolvimento de software
É impossível atingir 100% de cobertura nos testes

Como isto funciona tradicionalmente?
Design
Figure o que você quer fazer
Teste
Escreva um teste que expresse o seu design
Deve falhar
Implemente
Escreva o código de produção
Teste novamente
Deve passar

E se um defeito for encontrado?
Entenda o defeito
Figure o que está acontecendo
Teste
Escreva um teste que simule a falha
Deve falhar
Corrija o defeito
Escreva o código de produção para corrigi-lo
Teste novamente
Deve passar

E como eu faço com um sistema sem testes?
WTF?
Analise o código legado. Continue confuso.
Teste
Escreva um teste para entender o comportamento
Deve falhar
Adapte o teste
Iterativamente
Até passar
Vá para a próxima funcionalidade

Testes feitos depois, definitivamente, não é o mesmo que TDD
Cuide excessivamente
Mova-se (muito) devagar
Esteja preparado para abandonar suas melhorias
Acompanhe como uma trilha a cobertura de testes
O quanto do código de produção está coberto?
Quais áreas ainda precisam de testes?
Onde estão os maiores riscos?

Dublês de teste (test doubles)
Dummy
Objeto que passa de um lado pro outro sem ser utilizado
Fake
Objeto real, muito próximo a realidade (ou até melhor), mas...
Stub
Objeto implementado para simular comportamento,armazenando estado para verificação
Mock
objetos pré-programados com informações que formam uma especificação das chamadas que esperam receber.

Mock Objects
Verificam a interação entre objetos e não os seus estados
Devem ser projetados como uma interface; e não para um objeto específico
Especificam valores de retornos, exceções, números de chamadas, ordem das chamada

Boas práticas
Verifique o comportamento e não a implementação
Uma expectativa por teste
Não teste métodos privados
Não utilize mocks para todas as coisas
Diga ao invés de perguntar
Especifique o mínimo possível em um teste
Preste atenção aos “test smells”
Evite o uso de getters

Resumo
Nunca escreve um código sem um teste que falhe
Inicie de fora pra dentro, com os testes de aceitação
Projeto o design utilizando mocks de acordo com a necessidade
Os testes devem ser especificações descritivas
Falhe - Implemente - Refatore

http://danieltamiosso.com	222
http://www.danieltamiosso.com	28
http://visur.com.br	17
http://www.micromolas.com.br	15
http://www.studiourbano.com.br	11
http://micromolas.com.br	8
http://www.visur.com.br	8
http://www.grupocruzeirodosul.com	7
http://eaubranding.com	5
http://mail.mecasei.com	3
http://studiourbano.com.br	2
http://tarrasconi.com.br	2
http://216.154.216.80	2
http://www.tarrasconi.com.br	1
http://oldschool	1

Test-driven development & Mocking

by Daniel Tamiosso on Jul 27, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

15 Embeds 332

Statistics

Test-driven development & Mocking — Presentation Transcript