Измерять охват кода только по новому коду

Question

Мы ищем творческий способ измерить охват кода новым кодом отдельно от существующего кода.У нас большой унаследованный проект, и мы хотим начать получать покрытие более 90% на любую новую функциональность.Нам нужен способ легко просмотреть отчет, который отфильтровывает любой старый код, чтобы убедиться, что новая функциональность соответствует нашей цели.Очевидно, что все еще ожидают увеличения общего охвата проекта, но нужен не ручной способ, чтобы дать нам обратную связь о новой активности кода.У нас это работает для статического анализа, так как мы можем посмотреть даты в исходных файлах.Так как Cobertura анализирует файлы классов, у них есть новые даты, и эта техника не работает.

Есть идеи?

Стек:

Java 1.5 JUnit Cobertura Hudson

Answer 1

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

У нас есть файл с именем linecoverage.standard и файл branchcoverage.standard, который находится на сервере сборки (и локальные копии),У них есть номер внутри с текущей линией и пределами покрытия филиала.Если зарегистрированный код ниже стандарта, сборка завершается неудачно.Если он соответствует стандарту, он проходит сборку.Если он ВЫШЕ стандарта, новый стандарт пишется равным текущему покрытию.

Это означает, что покрытие кода никогда не ухудшится и должно постепенно увеличиваться.Если новый код составляет 90%, охват будет продолжать расти.Вы также можете поставить цель, например, повысить стандарт на 1 каждую неделю, пока не достигнете своей конечной цели (90%).Необходимость добавлять несколько тестов в неделю к старому коду не является плохой идеей, если он распространяется в течение достаточного времени.

Наше текущее покрытие составляет до 75%, что довольно неплохо, исходя из 0% ставка до года назад.

Answer 2

Я сделал это для большого проекта C ++, используя svn blame в сочетании с выводом gcov. Если вы объедините эти два результата вместе, у вас будет информация о редакции и информация о покрытии для каждой строки. Я фактически загрузил все это в базу данных для выполнения запросов (например, показывает мне все непокрытые строки, написанные joe начиная с r1234 ). Если вам нужно только общее число, вы можете просто не подсчитывать «старые» непокрытые строки в вашем итоге.

Answer 3

Просмотрите emma.sourceforge и связанный с ним плагин Eclipse здесь (если вы используете Eclipse)

Я думаю, что этот инструмент может удовлетворить ваши потребности, выбрав именно то, что нужно проверить на покрытие.

Answer 4

Мы сделали это, как показано ниже, используя свойство sonar.exclusion: Мы используем Sonar для отображения отчетов о покрытии кода (сообщает Cobertura).

a) Определите классы, для которых не требуется отчет о покрытии (Унаследованные классы) Используйте ваш клиент командной строки SCM.например: p4 files // depot / ... @ 2000/01/01, @ 2013/07/13 git log --until = "5 дней назад"

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

eg. the destination file is excludeFile.list should look like below:
abc.java
xyz.java
...

b) Теперь ... при интеграции с Sonar (из Jenkins Job)используйте свойство ниже.

    -Dsonar.exclusions=<filename>

И ваш окончательный отчет о покрытии в Sonar содержит только ваши новые классы (добавленные после 07/13 в приведенном выше примере).

Answer 5

IMO лучший вариант - разбить кодовую базу на разделы «новый» и «старый». Затем выполните анализ покрытия теста только в «новом» разделе или проигнорируйте результаты в «старом» разделе.

Два лучших способа сделать это: а) разделить кодовую базу на два дерева исходных текстов (два проекта с зависимостью между ними) или б) поддерживать две отдельные иерархии пакетов в одном проекте.

Возможно, предпочтительнее два отдельных проекта, но это может быть невозможно, если существует циклическая зависимость между устаревшей кодовой базой и новой кодовой базой (старый код зависит от нового кода, а новый код зависит от старого кода). Если вы можете управлять этим, односторонняя зависимость между старым и новым кодом также облегчит понимание объединенной кодовой базы.

Как только вы это сделаете, либо настройте cobertura так, чтобы он только анализировал нужные вам биты, или, по крайней мере, просто сосредоточьтесь на «новой» части кодовой базы. Еще один совет: в этой схеме лучше всего перемещать биты кода из «устаревшего» раздела в «новый», когда вы реорганизуете / добавляете в них тесты (если код часто перемещается в другом направлении, это не так). хорошо: -).