Покрытие Java-кода в Гудзоне - PullRequest
14 голосов
/ 14 сентября 2009

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

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

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

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

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

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


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

Ответы [ 6 ]

8 голосов
/ 03 октября 2009

Sonar - это очень крутой инструмент, который легко интегрируется с Hudson, мне очень нравится его организация с многомодульными проектами. Вам стоит попробовать

альтернативный текст http://sonar.codehaus.org/wp-content/uploads/2009/08/dashboard.png

6 голосов
/ 28 сентября 2009

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

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

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

1 голос
/ 03 октября 2009

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

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

1 голос
/ 23 сентября 2009

Рассматривали ли вы Клевер Атлассиана ?

Плагин maven-clover2-new имеет новую цель: clover2: настройка , которая будет просто выполнять тестирование, не прерывая жизненный цикл, или запускать тесты дважды.

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

mvn clover2:setup verify clover2:aggregate clover2:clover

Плагин maven-clover2-абсолютно бесплатен в течение 30 дней.

1 голос
/ 15 сентября 2009

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

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

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

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

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

1 голос
/ 15 сентября 2009

Роберт,

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

Jeff

...