Измеряйте покрытие кода только для нового кода

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

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

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

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

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

Взгляните на emma.sourceforge и соответствующий подключаемый модуль Eclipse здесь (если вы используете Eclipse)

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

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

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

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

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

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

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

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

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

б) Теперь... когда вы интегрируетесь с Sonar (из Jenkins Job), используйте свойство ниже.

    -Dsonar.exclusions=<filename>

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

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

Teamscale — это инструмент, который делает то, что вам нужно, и может обрабатывать отчеты Cobertura. Преимущество заключается в том, что вы просто измеряете охват, как обычно, а затем загружаете отчеты в Teamscale, который выполняет анализ пробелов в тестировании, чтобы выделить новый/измененный, но непроверенный код для каждого метода.

Полный отказ от ответственности: я работаю в компании CQSE, которая занимается разработкой Teamscale.