Eu li muitas coisas sobre TDD, mas ainda tenho dúvidas. Por exemplo, eu tenho esses diagramas de classes:
É 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.
Respostas:
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.
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.
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.
"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).