Обеспечить минимальный охват новых коммитов Subversion - PullRequest
12 голосов
/ 03 марта 2011

У нас огромный проект, в котором практически нет юнит-тестов. Теперь я хотел бы убедиться, что разработчики передают новые функции (или ошибки!) Без минимального покрытия для соответствующих модульных тестов.

Как можно это обеспечить?

Мы используем много инструментов, поэтому, возможно, я могу использовать плагин (jira, greenhopper, fisheye, sonar, hudson). Я также подумал, может быть, хук Pre-commit Subversion, плагин Commit Acceptance для jira или что-то подобное.

Мысли

Ответы [ 3 ]

6 голосов
/ 03 марта 2011

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

2 голосов
/ 03 марта 2011

Что вы хотите сделать, это определить, что является новым кодом, и убедиться, что новый код покрыт каким-то тестом.

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

Наши (Semantic Designs ') линейки инструментов покрытия тестов могут определять из списка измененных файлов только отдельные файлы, которые необходимо переинструментировать, а при тщательной организации тестов - только тесты это должно быть перезапущено. Это минимизирует стоимость повторного запуска ваших тестов, и вы все равно закончите с такими же данными общего покрытия. (На самом деле, эти инструменты определяют, какие тесты необходимо выполнить, основываясь на изменениях на уровне метода).

Если у вас есть данные о покрытии тестов, вам нужно знать, что конкретно новый код покрывается некоторыми тестами. Вы можете сделать это небрежно, просто протестировав данные покрытия, если вы знаете, какие файлы были изменены, настаивая на том, что измененные файлы имеют 100% покрытие. Это, вероятно, не работает на практике.

Вместо этого вы можете воспользоваться инструментами SD Smart Differencer , чтобы дать более точный ответ. Эти инструменты сравнивают два языковых файла и указывают, где изменения используют синтаксис языка (например, выражение, оператор, объявление, тело метода, а не только измененные исходные строки) и концептуальные операции редактирования (перемещение, копирование, удаление, вставка, переименование идентификатор-пределы-блока). Дельты SmartDifferencer имеют тенденцию быть как меньшими, так и более мелкими, чем то, что вы получили бы от простого инструмента сравнения.

Из вывода SmartDifferencer легко извлечь список измененных строк. Можно рассчитать пересечение этого для каждого файла со строками, покрытыми данными тестового покрытия. Если измененные строки не полностью находятся в пределах набора покрытых строк, то «новый» код не был протестирован, и вы можете поднять флаг, остановить проверку или что-то еще, чтобы сигнализировать, что ваша политика проверки была нарушена.

Инструменты TestCoverage и SmartDifferencer не выходят из коробки с этим вычислением, выполненным для вас, но это должен быть довольно простой сценарий для реализации.

0 голосов
/ 03 марта 2011

если вы используете maven - плагин cobertura может быть хорошим выбором (и не настолько раздражающим для разработчиков, как svn hook) http://mojo.codehaus.org/cobertura-maven-plugin/usage.html

...