Como a zombar construção do objeto?

Question

Existe uma maneira de construção objeto fictício usando JMock em Java?

Por exemplo, se eu tenho um método como tal:

public Object createObject(String objectType) {
    if(objectType.equals("Integer") {
        return new Integer();
    } else if (objectType.equals("String") {
        return new String();
    }
}

... há uma maneira de zombar a expectativa da construção objeto em um método de teste?

Eu gostaria de ser capaz de expectativas lugar que certos construtores estão sendo chamados, ao invés de ter um pouco mais de código para verificar o tipo (como ele não vai ser sempre tão complicada e simples como o meu exemplo).

Assim em vez de:

assertTrue(a.createObject() instanceof Integer);

Eu poderia ter uma expectativa de certa construtor sendo chamado. Apenas para torná-lo um pouco mais limpo, e expressar o que realmente está sendo testado em uma forma mais legível.

Por favor, desculpe o exemplo simples, o problema real que estou trabalhando é um pouco mais complicado, mas ter a expectativa seria simplificá-lo.

---

Para um pouco mais fundo:

Eu tenho um método de fábrica simples, que cria objetos de mensagens publicitárias. Os objetos de ser envolvido pode exigir parâmetros que são difíceis de obter em uma classe de teste (código-lo de pré-existente), por isso é difícil para construí-los.

Talvez mais perto do que eu estou procurando realmente é: existe uma maneira de zombar uma classe inteira (usando CGLIB) de uma só vez, sem especificar cada método para stub fora?

Assim, a simulação está sendo envolvido em um construtor, então obviamente métodos pode ser chamado sobre ele, é JMock capaz de dinamicamente zombando a cada método?

Meu palpite não é, como que seria muito complicado. Mas sabendo que eu estou latindo para a árvore errada é valioso demais: -)

Answer 1

A única coisa que posso pensar é ter o método de criar em pelo objeto de fábrica, o que faria com que simulada.

Mas em termos de zombar uma chamada de construtor, não. objetos mock pressupõem a existência do objeto, enquanto que um pressuposto construtor que o objeto não existe. Pelo menos em java onde a alocação e inicialização acontecer juntos.

Answer 2

JMockit pode fazer isso.

Veja a minha resposta em https://stackoverflow.com/questions/22697#93675

Answer 3

Infelizmente, eu acho que sou culpado de fazer a pergunta errada.

A fábrica simples que eu estava tentando teste parecia algo como:

public Wrapper wrapObject(Object toWrap) {
    if(toWrap instanceof ClassA) {
        return new Wrapper((ClassA) toWrap);
    } else if (toWrap instanceof ClassB) {
        return new Wrapper((ClassB) toWrap);
    } // etc

    else {
        return null;
    }
}

Eu estava fazendo a pergunta como encontrar se "novo ClassAWrapper) (" foi chamado porque o objeto toWrap era difícil de obter em um teste isolado. E o invólucro (se ele pode até mesmo ser chamado assim) é meio estranho, pois utiliza a mesma classe de envolver diferentes objetos, apenas usa construtores diferentes [1]. Eu suspeito que se eu tivesse feito a pergunta um pouco melhor, eu teria rapidamente recebeu a resposta:

"Você deveria zombar toWrap objeto para coincidir com as instâncias que você está testando para em diferentes métodos de ensaio, e inspecionar o objeto Wrapper resultante para encontrar o tipo correto é retornado ... e espero que você esteja bastante sorte que você don' t tem que zombar fora do mundo para criar as instâncias diferentes ;-) "

Agora tenho uma solução bem para o problema imediato, obrigado!

[1] abrindo a questão de saber se esta deve ser reformulado é bem fora do alcance do meu problema atual: -)

Answer 4

Você está familiarizado com Dependency Injection ?

Se não, então você ceartanly se beneficiaria de aprender sobre esse conceito. Eu acho que o bom e velho Inversão de Controle Containers ea dependência padrão de injecção por Martin Fowler servirá como uma introdução boa.

Com Dependency Injection (DI), você teria um objeto contêiner DI, que é capaz de criar todos os tipos de aulas para você. Em seguida, o objeto seria fazer uso do recipiente DI às classes instanciar e você zombar o recipiente DI para testar se a classe cria instâncias de classes esperados.

Answer 5

Dependency Injection ou inversão de controle.

Como alternativa, use o padrão de projeto Abstract Factory para todos os objetos que você cria. Quando você está em modo de teste de unidade, injetar uma fábrica de teste que vai dizer o que você está criando, então incluir o código de afirmação na Fábrica de Testes para verificar os resultados (inversão de controle).

Para deixar o seu código o mais limpo possível criar uma interface interna protegida, implementar a interface (sua fábrica) com o código de produção como uma classe interna. Adicionar um tipo variável estática da sua interface inicializada com o seu padrão de fábrica. Adicionar setter estático para a fábrica e está feito.

Em seu código de teste (deve estar no mesmo pacote, caso contrário, a interface interna deve ser público), criar um anônimo ou classe interna com o código de afirmação e o código de teste. Então, em seu teste, inicializar a classe alvo, assign (injeção) a fábrica de teste, e executar os métodos de sua classe-alvo.

Answer 6

Eu espero que não há nenhum. Mocks são supostamente para interfaces de simulação, que não têm construtores ... apenas métodos.

Algo parece estar errado na sua abordagem para testar aqui. Qualquer razão pela qual você precisa de teste que construtores explícitas estão sendo chamados?
Afirmando o tipo de objeto retornado parece bem para testar implementações de fábrica. createObject Tratar como uma caixa preta .. examinar o que ele retorna, mas micromanage não faça como ele faz isso. Ninguém gosta que:)

Update no Update: Ouch! Medidas desesperadas para tempos desesperados eh? Eu ficaria surpreso se JMock permite que ... como eu disse que trabalha em interfaces .. tipos não concreto. Então

• Ou tente e gastar algum esforço em obter 'instanciável' esses objetos de entrada traquinas sob o equipamento de teste. Vá fundo na sua abordagem.
• Se isso é inviável, testá-lo manualmente com pontos de interrupção (eu sei que é uma porcaria). Em seguida, manter um "toque-lo em seu próprio risco" comentário em uma zona visível no arquivo de origem e seguir em frente. Lutar outro dia.