Я не уверен, что это то, что вы делаете, но я все равно скажу это. Если вы создаете submodule1 как «код» и submodule2 как «тесты», это ужасный способ его организовать. Тесты (в частности, модульные тесты) должны храниться вместе с тестируемым кодом. Таким образом, каждый подмодуль имеет src/main/java и src/test/java.
Теперь, с учетом сказанного, вполне вероятно, что у вас есть модуль «common-lib», а затем дополнительные модули, которые зависят от этой библиотеки (например, уровень приложений). Весьма вероятно, что вы запускаете тест на уровне приложения, и он вызывает код в модуле lib. Но за это вы не получаете кредита на покрытие кода. Покрытие библиотеки Jacoco будет основано исключительно на тестах в библиотеке. Тесты «приложения» охватывают только приложение. Это связано с инструментированием, которое происходит при запуске jacoco - оно будет инструментировать только то, что является локальным для модуля, в котором он работает.
Да, есть отчет jacoco-aggregate, но он объединит отчеты модулей вместе — один отчет каждого модуля. Он НЕ дает вам унифицированного охвата теста уровня приложения, вызывающего методы lib и т. д.
Наконец, сонар. Я считаю, что пока у вас есть файлы jacoco, сонар-сканер будет их использовать. Я думаю, что он работает с необработанным файлом jacoco.exec, но может быть в состоянии интерпретировать jacoco-result.xml или jacoco-aggregate.xml. Если это вас огорчает, включите свой pom.xml
person
Jeff Bennett
schedule
14.12.2020
