Покрытие Java-кода в Хадсоне

Я переношу несколько проектов из сборки ant в maven. Сервер сборки будет и останется Hudson.

У меня возникли проблемы с записью кода покрытия в hudson с cobertura из-за тестов и записи дважды проблем.

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

В целом, решение, которое я ищу, должно:

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

Решение может быть основано на Cobertura, или Emma, ​​или на любом другом инструменте покрытия Java-кода.

Обновление: запуск тестов с помощью Emma по-прежнему дублирует результаты и там нет возможности merge, поэтому он не может использоваться с многомодульными сборками.

ОТВЕТЫ

Ответ 2

Это немного хакерский, но подход, который я использую, заключается в использовании измененной версии плагина Maven cobertura (который доступный из своего репо). Он обеспечивает кобруруру: цель создания отчета, так что вы можете вставлять cobertura: instrument и cobertura: генерировать отчет в свой жизненный цикл до и после запуска тестов соответственно. Это даст вам данные о покрытии, которые вы хотите, без повторного выполнения/записи теста.

Основная проблема заключается в том, что все плагины, не связанные с клевером Maven, которые я использовал, основаны на идее запуска тестов с покрытием отдельно от основного тестового исполнения в жизненном цикле Maven. Это, очевидно, приводит к двум наборам тестовых исполнений. Если вы используете проект фристайла, вы получите только один набор тестов (поскольку даже при двух тестовых исполнениях есть только одна копия тестового вывода), но тип проекта Maven фактически перехватывает выполнение Maven mojo и записывает результат теста/результаты во время выполнения теста, а не все сразу в конце сборки, как это делают фристайловые проекты. У этого есть много преимуществ, но у него также есть довольно вопиющий недостаток, заключающийся в том, что один тест, выполняемый дважды, засчитывается как два теста.

Тем не менее, несмотря на то, что я видел сильные аргументы в пользу тестирования тестов как с неинструментарным, так и с инструментальным кодом, я предпочитаю только один раз запускать тесты с инструментальным кодом - не только из-за проблем Maven/Hudson, но и потому, что когда у вас есть тесты, которые занимают 45 минут, кажется совершенно откровенно глупо запускать их дважды, чтобы получить тот же результат.

Ответ 3

Роберт

У меня была и эта проблема, и я обнаружил, что Хадсон не делает двойной отчет, если вы планируете проект как проект фристайла, а не проект Maven2. Вы теряете некоторую привлекательность проекта maven2, но для нас это была сделка, которую мы должны были сделать.

Джефф

Ответ 4

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

Чтобы обеспечить слияние функций, мы создали наш собственный артефактный репозиторий (мы не используем Maven). В конце каждой сборки мы копируем файл cobertura.ser в сетевой ресурс, переименовывая его в процессе. У нас есть сводная задача просмотра, которая копирует все файлы cobertura и файлы исходного кода (другой артефакт сборки, скопированный в общий сетевой ресурс) в локальный каталог сборки и генерирует отчет Cobertura.

Отсутствие стандартного хранилища артефактов в Хадсоне немного расстраивает, но имеет смысл дать авторам, как правило, использовать Maven для этих нужд. Наш процесс сборки выполняется на нескольких серверах, поэтому мы не можем просто использовать относительные пути в других каталогах заданий.

Обратите внимание: мы делаем то же самое для других показателей: результаты тестов, JavaNCSS, ect. и присоединились либо с использованием правильных инструментов, либо с помощью специального кода.

Мы используем тот же репозиторий для традиционных артефактов сборки: библиотеки DLL, JAR, сценарии установки.

Ответ 5

Вы считали Atlassian Clover?

У maven-clover2-plugin есть новая цель: clover2: setup, которая просто проверит ваши тесты без наложения жизненного цикла или запускает тесты дважды.

Вы бы определили цели для запуска в Хадсоне:

mvn clover2:setup verify clover2:aggregate clover2:clover

Maven-clover2-plugin абсолютно бесплатно попробовать в течение 30 дней.

Ответ 6

См. SD Java Test Coverage для чрезвычайно низкого накладного инструмента с приятным графическим интерфейсом. Я не уверен, что понимаю вашу проблему с "бегом дважды", но если вы дважды проведете (те же детерминированные) тесты с инструментами SD, вы получите те же данные о охвате проб, например, его идемпотент. Если ваши тесты недетерминированы, вы получите два разных тестовых прогона, но эти инструменты легко объединяют результаты нескольких запусков в единую общую сводку.

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