Эмма com.vladium.emma.EMMARuntimeException: [CLASS_STAMP_MISMATCH] - PullRequest
0 голосов
/ 24 января 2012

Хорошо, Эмма убивает меня.Я уже потратил на это два дня.

Сейчас есть две проблемы с Эммой

  1. Отказ происходит частично из-за модульного тестирования
  2. Это жалобы на несоответствие штампов классов.: com.vladium.emma.EMMARuntimeException: [CLASS_STAMP_MISMATCH] runtime version of class xxx in the coverage data is not consistent with the version of this class in the metadata, possibly because stale metadata is being used for report generation.

Хотя я могу жить со сбоями, это только часто, но я не собираюсь это исправлять,

INSTRUMENTATION_RESULT: shortMsg = Процесс сбой,[exec] INSTRUMENTATION_CODE: 0

Тем не менее, мне очень нравится видеть результат моего покрытия.

Я пытался:

  1. очистить устройство
  2. уничтожил всю рабочую область (в Jenkins)
  3. с помощью командной строки (обход jenkins, ant clean, тест установки отладки ant emma)

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

Я могу подтвердить, что в моем случае это НЕВОЗМОЖНО, поскольку я очищаю, очищаю и дажестер все рабочее пространство и память телефона.Это сейчас не имеет никакого смысла для меня.

Пожалуйста, ПОМОГИТЕ ~

Я использую Android SDK R16, NDK 5c и настройки по умолчанию от Ant и Emma.

Ответы [ 2 ]

0 голосов
/ 10 ноября 2014

Я тоже сталкивался с этой проблемой при использовании EMMA для Android. Это связано с тем, что файл range.ec, который вы извлекаете из sdcard, не согласуется с покрытием .em. Попробуйте восстановить инструментальную версию проекта. Попробуйте выполнить следующие действия:

  1. Муравьиный чистый релиз
  2. муравейник
  3. ant installi
  4. adb pull /mnt/sdcard/coverage.ec
  5. используйте файл cover.em (заново созданный в папке bin проекта на шаге 2) и cover.ec для генерации отчета о покрытии

Подробнее см. EMMA для Android .

0 голосов
/ 17 сентября 2012

Я вижу точно такую ​​же проблему с моим проектом Android (который использует стороннюю библиотеку с нативным кодом через JNI). Оказывается, в этом случае сообщение об ошибке EMMA слегка вводит в заблуждение. Это вызвано тем, что статически сгенерированные метаданные покрытия на хосте (cover.em) не соответствуют данным покрытия, собранным во время выполнения приложения на устройстве (cover.ec). На самом деле, это не только «несоответствие», но и абсолютно отсутствует cover.ec. Это происходит из-за сбоя в нативном коде: в Android сбой в нативном коде также отключает связанный процесс Java и фактически даже перезапускает виртуальную машину. Это означает, что EMMA также уничтожена, и у нее больше нет шансов записать файл cover.ec на диск, поэтому он отсутствует.

Я задавался вопросом, имеет ли смысл заставить EMMA более часто сбрасывать файл cover.ec перед сбоем, но опять же сомнительно, насколько ценной будет неполная информация о покрытии, как

  1. формат файла, вероятно, просто создан не так, чтобы иметь смысл разбирать его постепенно,
  2. частичное покрытие .ec по-прежнему не соответствует полному покрытию .em,
  3. покрытие, созданное из частичного покрытия .ec, сообщит о неправильном покрытии по всем вашим тестам в наборе.

Итак, короче говоря, лучший способ решить эту проблему - исправить исходный код, чтобы он не вылетал.

...