Я не знаю, почему вы хотите избежать изменения кода, но у вас могут быть свои причины. Вы не можете просто проверить, что супер-метод был вызван для шпиона. Тем не менее, вы все еще можете протестировать этот метод без изменения кода. Единственный способ сделать это - без шпиона. Другими словами, вам нужно будет проверить функциональность someMethod
с утверждениями или проверками на других издевательствах. Например, если класс Sup реализован тривиально, то:
class Sup {
private boolean somethingDone = false;
public boolean isSomethingDone() {
return somethingDone;
}
public void someMethod(){
somethingDone = true;
}
}
Тогда вы можете написать свой тестовый пример так:
@Test
public void testMethodArgIsNull() {
Sub s = new Sub();
s.method(null);
assertThat(s.isSomethingDone(), is(true));
}
Это, как говорится, вызов super.someMethod()
из чего-либо, кроме Sub.someMethod()
(которого не существует), выглядит как ошибка, ожидающая, чтобы произойти. Если Sub.someMethod()
не существует, то super.someMethod()
эквивалентно someMethod()
. Но если бы кто-то переопределил его в будущем, вы бы действительно хотели, чтобы method(Object o)
незаметно обошел его и в любом случае вызвал супер реализацию?
Позвонив по номеру super.someMethod()
, вы не получите ничего, кроме риска будущих ошибок.