Quando devo usar objetos simulados?

14

Eu li muitas coisas sobre TDD, mas ainda tenho dúvidas. Por exemplo, eu tenho esses diagramas de classes:

insira a descrição da imagem aqui

É um exemplo simples, apenas para aprender sobre TDD e objetos simulados.

Qual teste devo escrever primeiro? Produto , depois Linha e último, Pedido ? Se fizer isso, devo usar Linha e Produto para testar o Pedido ou devo usar Mock Objects? Quando devo usar o Mock Objects? Devo usar UML com XP e TDD?

Ainda não entendo essas coisas.

Zanon
fonte

Respostas:

10

A julgar pelo diagrama, Product é uma classe de dados idiota, sem funcionalidade para testar. Então, eu começaria a escrever testes para (e implementar, estilo TDD) primeiro Line e depois Order, subindo a escada de dependência. Geralmente, é sensato testar suas classes de nível inferior antes de iniciar o trabalho em classes de nível superior (ou seja, que dependem do nível inferior). Isso torna a captura de bugs mais eficiente.

A necessidade de usar objetos simulados depende das dependências reais da classe testada. Se essas são classes simples que você pode instanciar e configurar facilmente com qualquer dado / estado desejado necessário para seus testes, você não precisa de zombarias. (Esse parece ser o caso do seu exemplo de design aqui.) No entanto, se alguma das dependências for difícil de inicializar / tiver dependências extensas em si / tiver efeitos colaterais indesejáveis ​​/ depender de um recurso externo como um banco de dados, faz sentido para usar um objeto simulado.

Péter Török
fonte
Como eu disse antes, era um cenário simples, apenas para aprender sobre objetos TDD e Mock ... Uma ótima resposta, obrigado. E o que dizer da UML? Devo evitá-lo?
@ Thomas, não há necessidade de evitar UML, não entra em conflito com TDD. A UML é muito boa para visualizar / comunicar problemas de design. Isso pode ser extremamente útil em certos estágios de desenvolvimento. No entanto, o design evolui, e tentar manter um diagrama do sistema UML bonito e detalhado em sincronia com o código pode rapidamente se tornar um fardo. Portanto, lembre-se de jogá-lo fora quando não precisar mais dele :-)
Péter Török
1
@thomas, btw a convenção aqui é upvote respostas que você achar útil, clicando na seta para cima ao lado da resposta :-)
Péter Török
4

Não vejo muita necessidade de objetos simulados aqui. Conforme indicado por outras pessoas, você precisa delas principalmente se as dependências forem difíceis de configurar.

Por exemplo, nós os usamos com projetos Ruby on Rails quando testamos controladores e precisávamos de um login de usuário que exigisse uma chamada para outro controlador e armazenasse parte de suas informações em um cookie. Nesse caso, é útil zombar de um usuário conectado que retorne true, quando perguntado sobre um determinado privilégio de acesso.

thorsten müller
fonte
2

Normalmente, para o teste, você deseja isolar o sistema / objeto em teste, para que você zombe de qualquer coisa que esteja fora dele. Portanto, ao usar o diagrama de classes, ao testar um objeto de pedido, use uma simulação para o objeto de linha. Ao testar o Line, use uma simulação para Pedido e Produto. Ao testar o produto, use mock para Line.

Gelo preto
fonte
Como o Produto não depende da Linha, não há necessidade (nem maneira) de usar uma simulação para a Linha lá. O mesmo para Linha e Pedido.
Péter Török
2

"O TDD é principalmente uma técnica de design com um efeito colateral de garantir que seu código-fonte seja minuciosamente testado por unidade" - Scott W. Ambler

A idéia é encontrar o design escrevendo testes de unidade. No seu caso, parece que você já possui o design, o que meio que derrota o objetivo do TDD (supondo que seu design seja final).

Em relação à zombaria. Se você quiser zombar, sugiro que você zombe de Produto ao escrever testes para Linha e zombe de Linha ao testar Ordem. Mas pode ser um exagero aqui. Eu, pessoalmente, tento limitar a zombaria o máximo possível e usá-la para dissociar dependências de classes externas (como instâncias de banco de dados).

Martin Wickman
fonte
2
Eu só tenho um diagrama de classes simples ...
-1 Então, pensar no design (incluindo rabiscar um diagrama de classes) impede que você faça TDD? Isso parece errado.
Bjarke Freund-Hansen
1
@ bjarkef: Leia minha resposta novamente, por favor. Se o design for final, você não poderá realmente usar o TDD para expulsá-lo, que é o objetivo do TDD. E acho que também é isso que confunde o OP: ele já tem uma solução e agora está tentando escrever testes para ele. "Quais testes devo escrever primeiro, Produto ou Pedido". Essa pergunta não é realmente relevante se você escrever testes primeiro.
Martin Wickman
Como você determina que o design é final sem testes ou código de produção? Supondo que você queira criar algo que funcione.
Jeffo
@ Jeff: Você não pode, obviamente. Isso é uma coisa que o TDD pode ajudá-lo.
Martin Wickman