Eu acredito que este é um dos casos em que usar reset()
está ok. O teste que você está escrevendo está testando que "algumas coisas" aciona uma única chamada para someMethod()
. Escrever a instrução verify()
com qualquer número diferente de invocações pode causar confusão.
-
atLeastOnce()
permite falsos positivos, o que é uma coisa ruim, pois você quer que seus testes estejam sempre corretos. -
times(2)
impede o falso positivo, mas faz parecer que você está esperando duas invocações, em vez de dizer "eu sei que o construtor adiciona uma". Ainda mais, se algo mudar no construtor para adicionar uma chamada extra, o teste agora tem uma chance de um falso positivo. E remover a chamada faria com que o teste falhasse porque o teste agora está errado, em vez de o que está sendo testado está errado.
Ao usar reset()
no 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, esteja avisado. O principal motivo pelo qual reset()
é desencorajado é evitar
bar = mock(Bar.class);
//do stuff
verify(bar).someMethod();
reset(bar);
//do other stuff
verify(bar).someMethod2();
Isso não é o que o OP está tentando fazer. O OP, estou assumindo, tem um teste que verifica a invocação no construtor. Para este teste, o reset permite isolar esta única ação 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 que o OP fez este post mostra que ele está pensando sobre a situação e não apenas cegamente utilizando o método de reset.