Mockito - странная проблема наследования класса области пакета

Обнаружил очень интересную проблему и после отладки нашел сценарий для ее воспроизведения.

Итак, если у меня есть класс с областью действия пакета B, который имеет некоторый общедоступный метод и общедоступный класс A, который его расширяет:

package somepackage;

class B {
   public void someMethod() {
      throw NullPointerException();
   }
}

package somepackage;
public class A extends B {

}

а потом в тесте:

A a = mock(A.class);
a.someMethod();

и угадайте, что я получаю исключение NullPointerException, которое я только что бросил, поэтому Mockito каким-то образом создает «настоящий» объект и вызывает настоящий метод вместо издевательства. Почему так?

java.lang.IllegalArgumentException
    at test.B.setProxy(B.java:6)
    at test.A.setProxy(A.java:1)
    at secretservice.service.TestFDSServiceImpl.testService(TestFDSServiceImpl.java:17)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

В приведенном выше примере у меня есть IllegalArgumentException, поскольку я изменил его в классе B, чтобы убедиться, что NullPointerException не вызвано чем-то другим.

Eclipse: Juno Service Release 1, идентификатор сборки: 20120920-0800 Mockito: 1.8.4 (также протестировано с 1.9.5) JUnit: 4.10


person potomok    schedule 02.12.2013    source источник
comment
Вы можете проверить, выполнив a.getClass() или отладку.   -  person Sotirios Delimanolis    schedule 02.12.2013
comment
это класс test.A$$EnhancerByMockitoWithCGLIB$$edd8e028, поэтому я предполагаю, что он просто не может издеваться над общедоступным методом из класса области пакета   -  person potomok    schedule 02.12.2013
comment
Ваш фиктивный объект не завершен. Вы должны использовать when(), чтобы придать ему какое-то поведение.   -  person Moritz Petersen    schedule 02.12.2013
comment
Действительно? Почему он не полный? Насколько я понимаю, это должно вызывать тупой издевательский метод, но он вызывает реальную причину. Если я это сделаю, этот метод все равно будет вызываться... Кстати, если я изменю область B на общедоступную, все будет работать так, как ожидалось.   -  person potomok    schedule 02.12.2013
comment
Хм. Я только что попробовал ваш пример, и у меня он работает без выбрасывания NPE...   -  person Moritz Petersen    schedule 02.12.2013
comment
Хорошо, круто, так что это исправлено. Какая у вас мокито версия? у меня 1.8.4   -  person potomok    schedule 02.12.2013
comment
Я только что попробовал с 1.9.5, у меня все еще такое же исключение. Кстати, я полагаю, вы нашли свой тест в другом пакете? Таким образом, класс B не виден тесту   -  person potomok    schedule 02.12.2013
comment
Нет, здесь еще нет проблем. Я имею в виду: B не виден ATest, и я не получаю NPE.   -  person Moritz Petersen    schedule 02.12.2013
comment
Я могу воспроизвести это. Очень странный.   -  person Tom McIntyre    schedule 02.12.2013
comment
действительно странно, я обновил вопрос, за исключением того, что у меня есть :(   -  person potomok    schedule 02.12.2013
comment
Это не NPE, это IllegalStateException.   -  person Moritz Petersen    schedule 02.12.2013
comment
К сожалению, извините, в моем примере я просто хотел убедиться, что NullPointer не вызван чем-то другим, поэтому я изменил его на недопустимое состояние, сейчас я обновлю вопрос. Кстати, вы тестировали с junit или что-то еще?   -  person potomok    schedule 02.12.2013


Ответы (1)


изменить

В последней бета-версии mockito 2.x теперь используется ByteBuddy, на который эта проблема не влияет. Там могут быть некоторые настройки API, но они в значительной степени работают и функциональны. Также будет нарушена совместимость с существующими сопоставителями mockito. Если это нормально для проекта, было бы здорово получить отзыв об API, пока mockito 2 находится в стадии бета-тестирования.

исходный

Существует известная проблема, когда у фиктивного класса есть непубличный родитель. Метод нельзя заглушить. См. проблему 212.

Проблема в том, что компилятор генерирует методы моста для доступа к методу из родителя, однако это сбивает с толку инструменты байт-кода, такие как CGLIB. Если вы не можете исправить CGLIB, реального решения не существует.

Извините, вам нужно обойти это по-другому :/

person Brice    schedule 02.12.2013
comment
Спасибо за это, да, я решил пойти на очень глупое решение, просто создав еще один класс, который наследуется от общедоступного класса и переопределяет все нереализованные методы, к счастью, в моем случае они просто сеттеры - person potomok; 02.12.2013