У нас есть массивный проект, в котором почти нет никаких модульных тестов. Теперь я хочу, чтобы разработчики фиксировали новые функции (или ошибки!) Без минимального охвата соответствующих модульных тестов.
Какими способами можно обеспечить это?
Мы используем много инструментов, поэтому, возможно, я смогу использовать плагин (jira, greenhopper, fisheye, sonar, hudson). Я также думал, что, возможно, был захват Subversion pre-commit, плагин Accept Accepting для джиры или что-то подобное.
Мысли?
Сонар (замечательный инструмент кстати) с Плагин Build breaker может сломать вашу сборку Hudson, когда некоторые показатели не соответствуют указанным правилам. Вы можете установить такое правило в Sonar, которое вызовет предупреждение (в конечном итоге приведет к сбою сборки), когда покрытие будет ниже заданной точки. Единственным недостатком является то, что вы, вероятно, хотите, чтобы покрытие увеличивалось, поэтому вы должны помнить, что каждый день повышайте уровень предупреждений до текущего значения.
Что вы хотите сделать, это определить, что такое новый код, и проверить, что новый код покрывается некоторым тестом.
Определение покрытия кода в целом может быть выполнено с помощью любого из множества инструментов для тестирования. Многие инструменты для тестирования могут просто восстановить все ваше приложение, а затем вы можете запускать тесты для определения покрытия.
Наши (семантические проекты) строка тестового покрытия инструменты могут определять из списка измененных файлов только отдельные файлы, которые необходимо переоснащен и тщательно организованную организацию тестирования - это просто те тесты, которые необходимо выполнить повторно. Это позволит свести к минимуму затраты на повторное выполнение ваших тестов, и вы все равно закончите с теми же данными общего охвата. (На самом деле, эти инструменты определяют, какие тесты должны быть сделаны на основе изменений на уровне метода).
Как только у вас есть данные тестового покрытия, то, что вы хотите знать, - это то, что специально новый код покрывается некоторыми тестами. Вы можете сделать это slobpily с помощью только данных покрытия, если вы знаете, какие файлы были изменены, настаивая на том, что измененные файлы имеют 100% -ный охват. Вероятно, это не работает на практике.
Вместо этого вы можете использовать SD инструменты Smart Differencer, чтобы дать более точный ответ. Эти инструменты сравнивают два языковых файла и указывают, где изменения используют синтаксис языка (например, выражение, оператор, декларация, тело метода, а не только измененные исходные строки) и концептуальные операции редактирования (перемещение, копирование, удаление, вставка, идентификатор-пределы-блока). Дельты SmartDifferencer имеют тенденцию быть как меньшими, так и более тонкими, чем то, что вы получите от простого инструмента сравнения.
Из вывода SmartDifferencer легко извлечь список измененных строк. Можно вычислить пересечение этого в каждом файле строк, охватываемых данными тестового покрытия. Если измененные строки не все полностью входят в набор покрытых линий, тогда "новый" код не был протестирован, и вы можете поднять флаг, остановить проверку или что-то еще, чтобы сигнализировать о нарушении вашей политики проверки.
Инструменты TestCoverage и SmartDifferencer не выходят из коробки с этим вычислением, выполненным для вас, но это должно быть довольно просто script для реализации.
если вы используете maven - плагин cobertura может быть хорошим выбором (и не настолько раздражающим для разработчиков, как svn hook) http://mojo.codehaus.org/cobertura-maven-plugin/usage.html