Esse é um uso apropriado do método de redefinição do Mockito?

Eu tenho um método privado na minha classe de teste que constrói um Barobjeto comumente usado . O Barconstrutor chama o someMethod()método no meu objeto zombado:

private @Mock Foo mockedObject; // My mocked object
...

private Bar getBar() {
  Bar result = new Bar(mockedObject); // this calls mockedObject.someMethod()
}

Em alguns dos meus métodos de teste, eu quero verificar someMethodtambém foi invocado por esse teste específico. Algo como o seguinte:

@Test
public void someTest() {
  Bar bar = getBar();

  // do some things

  verify(mockedObject).someMethod(); // <--- will fail
}

Isso falha, porque o objeto simulado foi someMethodchamado duas vezes. Eu não quero que meus métodos de teste se preocupem com os efeitos colaterais do meu getBar()método, então seria razoável redefinir meu objeto simulado no final de getBar()?

private Bar getBar() {
  Bar result = new Bar(mockedObject); // this calls mockedObject.someMethod()
  reset(mockedObject); // <-- is this OK?
}

Eu pergunto, porque a documentação sugere a redefinição de objetos simulados geralmente é indicativa de testes ruins. No entanto, isso parece bom para mim.

Alternativa

A escolha alternativa parece estar chamando:

verify(mockedObject, times(2)).someMethod();

o que, na minha opinião, força cada teste a conhecer as expectativas de getBar(), sem nenhum ganho.

Eu acredito que este é um dos casos em que o uso reset()está ok. O teste que você está escrevendo está testando que "algumas coisas" acionam uma única chamada someMethod(). Escrever a verify()declaração com qualquer número diferente de invocações pode causar confusão.

• atLeastOnce() permite falsos positivos, o que é uma coisa ruim, pois você deseja que seus testes estejam sempre corretos.
• times(2)evita o falso positivo, mas faz parecer que você espera duas invocações em vez de dizer "eu sei que o construtor adiciona uma". Além disso, se algo mudar no construtor para adicionar uma chamada extra, o teste agora tem uma chance de um falso positivo. E remover a chamada causaria falha no teste, porque agora o teste está errado, e não o que está sendo testado.

Ao usar reset()o método auxiliar, você evita esses dois problemas. No entanto, você precisa ter cuidado para que ele também redefina qualquer stub que você tenha feito, portanto, seja avisado. O principal motivo reset()é desencorajado é evitar

bar = mock(Bar.class);
//do stuff
verify(bar).someMethod();
reset(bar);
//do other stuff
verify(bar).someMethod2();

Não é isso que o OP está tentando fazer. O OP, suponho, tem um teste que verifica a invocação no construtor. Para este teste, a redefinição permite isolar essa ação única e seu efeito. Este dos poucos casos com reset()pode ser útil como. As outras opções que não usam tudo têm contras. O fato de o OP ter feito esse post mostra que ele está pensando sobre a situação e não apenas utilizando cegamente o método de redefinição.

Usuários inteligentes do Mockito dificilmente usam o recurso de redefinição porque sabem que isso pode ser um sinal de testes ruins. Normalmente, você não precisa redefinir suas simulações, basta criar novas simulações para cada método de teste.

Em vez de reset()considerar, escreva métodos de teste simples, pequenos e focados em testes longos e superespecificados. O primeiro cheiro potencial de código está reset()no meio do método de teste.

Extraído dos documentos mockito .

Meu conselho é que você tente evitar o uso reset(). Na minha opinião, se você chamar duas vezes para someMethod, isso deve ser testado (talvez seja um acesso ao banco de dados ou outro processo longo que você queira cuidar).

Se você realmente não se importa com isso, você pode usar:

verify(mockedObject, atLeastOnce()).someMethod();

Observe que esse último pode causar um resultado falso, se você chamar someMethod de getBar, e não depois (esse é um comportamento errado, mas o teste não falhará).

Absolutamente não. Como costuma acontecer, a dificuldade que você está enfrentando para escrever um teste limpo é uma grande bandeira vermelha sobre o design do seu código de produção. Nesse caso, a melhor solução é refatorar seu código para que o construtor de Bar não chame nenhum método.

Construtores devem construir, não executar lógica. Pegue o valor de retorno do método e passe-o como um parâmetro construtor.

new Bar(mockedObject);

torna-se:

new Bar(mockedObject.someMethod());

Se isso resultar na duplicação dessa lógica em muitos lugares, considere criar um método de fábrica que possa ser testado independentemente do seu objeto Bar:

public Bar createBar(MockedObject mockedObject) {
    Object dependency = mockedObject.someMethod();
    // ...more logic that used to be in Bar constructor
    return new Bar(dependency);
}

Se essa refatoração for muito difícil, usar reset () é uma boa solução. Mas vamos deixar claro: isso indica que seu código foi mal projetado.