2009-12-01 3 views
2

Я пытаюсь использовать jMockit для вызова вызова netscape.javascript.JSObject, который, к сожалению, является абстрактным классом с несколькими встроенными методами в нем, оба из которых не играют хорошо с jMockit. Есть ли какой-нибудь способ для меня заглушить это, либо с помощью jMockit, либо с помощью простой java (я бы предпочел не добавлять новую библиотеку, если это возможно)? Код, который я пытаюсь ввести в mock, выглядит примерно следующим образом (не спрашивайте):Как скомпилировать собственные методы с помощью jMockit

JSObject win = JSObject.getWindow (this);
String someVal = (String) win.call ("foo", new String [] {""});

К сожалению, я не могу изменить код, о котором идет речь (еще раз, не спрашивайте), поэтому единственный способ, который я могу выполнить с помощью какого-либо модульного тестирования, - это выяснить, как заглушить или иным образом устранить призывы к JSObject. Моя текущий макет реализация возвращает новый экземпляр себя для вызова GetWindow и возвращает постоянную строку для вызова вызова но, конечно, он не во время выполнения жалуясь

класса переопределения не удалось: попытка для модификации модификаторов метода

, который из моих исследований, которые я обнаружил, означает, что он пытается высмеять собственный метод.

Редактировать: Из-за целевой платформы мне нужно использовать JDK 1.5 для сборки/тестирования, поэтому любое решение должно быть жизнеспособным на 1.5.

ответ

3

Какая версия JMockit вы используете? Согласно this, вы сможете без проблем набросать собственные методы.

@Test 
public void mockNativeMethod() { 
    new MockUp<Runtime>() { 
     @Mock 
     @SuppressWarnings("unused") 
     int availableProcessors() { 
      return 999; 
     } 
    }; 
    assertEquals(999, Runtime.getRuntime().availableProcessors()); 
} 

EDIT: Как вы уже отметили, это не работает с Java 1.5. Я боюсь, что единственное решение - обернуть ваши собственные объекты декоратором, который просто работает как сквозной. Это немного головная боль, но это позволит насмехаться/перехватывать и т. Д.

+0

Я использую самую последнюю версию, но проблема в том, что я вынужден использовать JDK 1.5, который не предоставляет интерфейс, чтобы позволить инструментальным средствам нативных методов, необходимых для их издевательства. – Orclev

1

Как указал Брайан, JMockit поддерживает насмешку собственных методов. (Ожидания по API, показанный в приведенном ниже тесте, а также поддерживает его.)

@Test // this only works under JDK 1.6+; JDK 1.5 does not support redefining natives 
public void mockNativeMethod() 
{ 
    new Expectations() 
    { 
     final System system = null; 

     { 
     System.nanoTime(); returns(0L); 
     } 
    }; 

    assertEquals(0, System.nanoTime()); 
} 

Проблемы, однако, заключается в том, что осуществление JVMTI в JDK 1.5 не очень зрелое, не поддерживает переопределение native методов.

Насколько я понимаю, вам необходимо развернуть производственный код в среде JDK 1.5, но это не должно препятствовать использованию JDK 1.6 в вашей среде разработки. Как правило, должно быть совершенно безопасно и легко запускать тесты на JDK 1.6 и даже скомпилировать весь исходный код с помощью компилятора JDK 1.6. Вам просто нужно указать javac «target» как «1.5». В Eclipse существует конфигурация «Соответствие JDK» в разделе «Свойства проекта -> Компилятор Java».