2014-01-07 3 views
0

Поскольку мы обновили flex sdk в нашем приложении до 4.10, мы работали с Verify Errors при запуске модульных тестов, которые используют mockolate.Mockolate Verify Error: Незаконное переопределение .. после обновления Flex SDK 4.10

Они, похоже, возникают при издевательском интерфейсе, в котором используется сигнатура метода ByteArray.

Пример интерфейса:

public interface IFileSystemHelper { 

    function loadFileContents(path:String):ByteArray; 

} 

Пример тестового класса:

public class SomeTest { 

    [Rule] 
    public var mockolateRule:MockolateRule = new MockolateRule(); 

    [Mock] 
    public var fileHelper:IFileSystemHelper; 

    public function SomeTest() { 
    } 

    [Test] 
    public function testMethod():void { 
     // ... 
    } 
} 

При компиляции и запуска теста с flexmojos 6.0.1 брошено следующее сообщение об ошибке:

VerifyError: Error #1053: Illegal override of IFileSystemHelper8F2B5D281827800A824B85B588C6F2A08AE814ED in mockolate.generated.IFileSystemHelper8F2B5D281827800A824B85B588C6F2A08AE814ED

Мои Первоначальное подозрение было проблемой версии sdk с playerglobal (или airglobal в нашем случае), поэтому я перекомпилировал moc kolate (и flexunit) с sdk 4.10 без каких-либо результатов.

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

Есть ли кто-нибудь у кого была аналогичная проблема?

Благодаря

+0

Итак, у меня есть интерфейс. IFileSystemHelper и mockolate генерируют класс для «реализации» макета. Вы действительно можете увидеть сгенерированный код где-нибудь? Судя по этому другому сообщению http://stackoverflow.com/questions/4450302/mockolate-suddenly-getting-verifyerror-illegal-override, в конечном итоге ваша проблема в том, что вы изменили подпись IFileSystemHelper, но сгенерированный макет кода не был обновлен ? Поэтому старый сгенерированный класс допустил бы незаконное переопределение, потому что подписи не совпадают? –

+0

Подпись этого метода не изменилась и не прошла тест. Я еще не посмотрел на сгенерированный код, я дам, что сначала пойдем, тх для указателя! :-) – Bert

+0

Нечего странно видеть на сгенерированных источниках и подписях, я боюсь – Bert

ответ

0

Эта проблема обычно возникает при компиляции различных частей вашего приложения с различными версиями SDK.

Я бы порекомендовал взглянуть на вывод «mvn dependency: tree», так как это должно выводить все зависимости (прямые и транзитивные). Возможно, это поможет вам найти, откуда происходит неправильная версия.

+0

Эй, Крис, это тоже было мое первое предположение, но проверка зависимостей не привела к большому :-). – Bert

+0

Я даже выделил проблему в отдельном проекте, используя только необходимые гибкие и воздушные зависимости, mockolate & flexunit. (таким образом, исключая любую проблему с другими зависимостями). Я добавил только пример интерфейса и теста, упомянутого выше, но без везения. – Bert

+0

Другая проблема может заключаться в том, что вы используете rsls или обычные libs, которые включили классы framework (Сортировка статически связанных библиотек), но я думаю, это немного сложнее узнать. Вы можете использовать IntelliJ, чтобы сообщить вам, откуда он получает класс ByteArray. Если он найдет это более чем в одном, у вас проблемы. Я не знаю, сможет ли FB это сделать. Если не открывать libs с помощью zip-инструмента и смотреть на манифест, это должно помочь.Судя по вашему второму комментарию, возможно, что mockolate включает в себя sataically-связанный класс? –

Смежные вопросы