Встретил вот такое описание:


JaCoCo a coverage analysis tool. It runs as a JVM Agent and therefore does not require offline instrumentation.

Объясните плиз почему JaCoCo не требует offline инструментации?

BlazkowiczПотому что JVM Agent позволяет инструментировать классы на лету.

А на лету и не на лету это как ?

BlazkowiczНе на лету, это предварительно, до или после компиляции.
На лету, это во время исполнения в JVM.
Основные способы реализации подобного АОП
1) Кодогенераторы\Прекомпиляторы - пишем специальные инструкции, прекомпилятор их конвертирует в Java код. Дальше компиляция и как обычно.
2) Посткомпиляция - скомпилировали в байт-код, запустили тулзу, которая парсит байт-код и добавляет нужные инструкции.
3) Load time weaving - принципе аналогичен пост-компиляции, но уже почти "налету". Перехватываем чтение байт-кода ClassLoader-ом и подменяем байт-код перед тем как скормить ClassLoader-у
4) JVM Agent Instrumentation - правим код в любой момент на лету, аналогично hot swap в дебаге.

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

Зачем для определения coverage вообще нужная инструментация?

maytonКстати коллеги. Кто знает родословные продуктов:

- Cobertura
- Emma
- Jacoco

Расскажите. Какой есть форк от какого? Какой в настоящий момент в разработке? Какой в поддержке?
Какой в тренде или какой вы используете на проекте.

Надо освоить в короткий срок а времени как всегда не хватает.

говорят, что jacoco это преемник Emma http://stackoverflow.com/tags/jacoco/info

BlazkowiczquestionerЗачем для определения coverage вообще нужная инструментация?
Чтобы отслеживать какие методы выполнены.
Если очень отдалённо, то после каждой строки кода вставляется какой-то вызов jacoco по которому анализируется была ли вызвана строка кода?

забыл ник,

Окей. главное, что в общих чертах механизм я понял.

Теперь хочу понять чуть больше)

Получается, что jacoco запускает какой-нить runner тестов и анализирует(инструментирует) все классы(видимо все не тестовые классы), которые лоадятся класслоадером.

Но мы знаем, что runner для powermock тоже инструментирует код. Видимо с дефолтными настройками jacoco просто игнорит тесты, которые надо запускать powermockRunner-ом.

на stackoverflow есть вот такой вот совет например:

http://stackoverflow.com/questions/23983740/unable-to-get-jacoco-to-work-with-powermockito-using-offline-instrumentation


Но он на самом деле не работает.

Хотелось бы понять в чем суть проблемы для начала.

Blazkowicz,

гуглинг этого вопроса наводит на то, что надо включить offline инструментацию, а не на лету как по умолчанию.

Хочется понять почему это поможет.

http://www.eclemma.org/jacoco/trunk/doc/offline.html One of the main benefits of JaCoCo is the Java agent, which instruments classes on-the-fly. This simplifies code coverage analysis a lot as no pre-instrumentation and classpath tweaking is required. However, there can be situations where on-the-fly instrumentation is not suitable, for example:

Runtime environments that do not support Java agents.
Deployments where it is not possible to configure JVM options.
Bytecode needs to be converted for another VM like the Android Dalvik VM.
Conflicts with other agents that do dynamic classfile transformation.
For such scenarios class files can be pre-instrumented with JaCoCo, for example with the instrument Ant task. At runtime the pre-instrumented classes needs be on the classpath instead of the original classes. In addition jacocoagent.jar must be put on the classpath.


это тот вариант?

up

up