Расчет покрытия кода (code coverage)

#1

Пытаюсь решить две задачи.

  1. Процент покрытия тестами кода (собственно).
  2. Оптимизация проверки коммитов тестами.

Насчет первого всё более-менее понятно:

Насчет пункта “два”, я ещё не определился.
Смысл действа в том, чтобы при каждом коммите не прогонять все тесты, а только те что действительно пересекаются с данным коммитом. Это имеет смысл, когда имеем группу разработчиков (у меня 7 человек), которые делают много мелких коммитов. Если на каждый из них делать полный прогон тестов, то легко получить ситуацию, когда сервер, занимающийся будет затыкаться.
Ситуация более чем реальна, т.к. есть примеры проектов, где прогон всех тестов уже занимает больше 20 минут, а степень покрытия тестами сильно далека от 100%. Т.е. если за час каждый разработчик сделает по одному коммиту (что довольно мало), то уже получаем два часа тестов. Следовательно получаем медленную реакция системы на “поломку” теста. В идеале хочется увидеть это мгновенно.
Поэтому хочу при активной разработке сделать прогон только необходимых для этого коммита тестов.
Для этого:

  • для каждого теста вычисляются модули, с которыми он работает
  • для каждого коммита вычисляются модули, которые он затронул
  • запускаем тесты из пересечения данных множеств
  • профит

Есть ли у кого идеи, как это всё лучше хранить и рассчитывать?
Буду признателен за конструктив.

ЗЫ: Замечу, что при ночном билде остаётся полный запуск ВСЕХ тестов. Это никуда не девается.

2 Симпатий
#2

Пока вспомнил следующее по второму пункту

задача далека от покрытия кода тестами, но зато близка к частичному запуску тестов.
То есть есть 2 посыла:

  1. тесты прогоняются методоми

    RunTestsByFeatureName(Фича)
    RunTestsByStory(История)
    RunTestByStepName(ИмяШага)

  2. разработчик при коммитах запускает только тесты функциональности с которой сейчас работает.

пока то что вспомнил

#4

@artbear Можно будет с ними чуть подробней поговорить про это на Inffostart Event. Правда тема доклада Евгения НЕ совсем по нашей тематике, но всё же.

P.S. Хотя подход @pumbaE все таки интересней - получается работа со штатным замером

#5

Насколько помню, не весь код мог отработать. Любые конструкции несовместимые с 1С стандартами вызывают ступор в подменке и не всегда возможно полностью автоматизировать подмену кода.

Структура вызовов можно с помощью соответсвующего скрипта в снегопате получить - там скрипт последовательно нажимает F11 и получаете в результате дерево процедур и функций.

#6

Интересно чем они cf обратно собирают, а то у штатных механизмов платформы есть проблемы (хотя они могут быть не критичны для их задачи, модули собираются правильно).

#7

Я думал о снегопате - но он платный, это не очень хорошо для опенсорс решения.
У меня ещё есть такая идея:
запускаем отладку и перехватываем сообщения, которые клиентский сеанс шлёт в конфигуратор и сами их логируем. Ничего собирать/разбирать не придётся. Орефков может подсказать, как грамотно заинжектица для перехвата сообщений.

#8

аналого autoit и объединение конфигураций.

#9

В смысле? Это без разбора конфы происходит? Просто эмулируют нажатие клавиатуры?

#10

нет, первоначальные объекты они вставляют с помощью объединения конфы, а потом уже только модули выгружают и там делают подменку.

#11

Поговорил с Орефковым. Он посоветовал глянуть скрипт watch_ext.
Спасибо Андрею Овсянкину, помог разобраться.
В общем этот путь предполагает эмуляцию нажатия F11 в конфигураторе (если грубо). Это не то, что я бы хотел.

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

#13

Я тут на днях разобрался как работает замер производительности.
Снифер не нужен.
Когда в конфигураторе жмёшь часики - на клиент шлётся команда вести лог.
В итоге на клиентской стороне формируется таблица, где записано какой модуль и какая строка выполнялась.
Когда часики отжимаешь - вся таблица за один раз переезжает в конфигуратор и мы видим отчет “Замер производительности”.
Я нашел где и как эти данные формируются на клиенте, и в принципе можно заинжектица и самому вести свой лог, но всё-равно надо чтобы был включен замер производительности, иначе эти данные не будут формироваться.

2 Симпатий
#14

А случайно нет какого-нибудь параметра запуска клиента, чтобы он работал в режиме “замера производительности”? Или может ему можно передать какой-нибудь флаг-файл, чтобы он начал формировать у себя такую табличку?

#15

Я думал об этом.
Но это уже путь, когда надо делать полноценный инжект, со всеми вытекающими проблемами. Т.е. придётся каждый новый релиз 1С проверять на совместимость с инжектом.
В общем побыть в шкуре разработчика снегопата.
Хочется всё-таки максимум штатной работы.

#16

Может связаться с Сашей Орефковым и узнать, насколько функционал вызова замера меняется от версии к версии?

#17

Кстати, есть вот такая штука для оценки и учета метрик кода: http://nemo.sonarqube.org/
По ссылке - аналитика для популярных open-source проектов.
Как вы считаете, коллеги, нужно ли что-то такое в 1с-world? Туда можно впилить плагин для поддержки языка.

#18

Такое нужно, и qube в названии должно было тебя натолкнуть на мысль, что кто-то это уже попробовал.
Года 2 назад я начинал именно с Sonar’а, опыт был негативный - мы сделали ошибку, которую потом кстати уже при разработке мониторинга старались не допускать.

Метрики в 1С, к ним приходится подходить как к НИОКР - то есть вначале смысловая нагрузка, а уже потому инструментарий.

P.S. Плюс очень долго пришлось разбираться с самим SONAR’ом в части написания своего плагина и настроек дополнительный rules’ов - для 1С пришлось начинать именно с них.

#19

которую потом кстати уже при разработке мониторинга старались не допускать.

  1. Ты какой мониторинг имеешь ввиду?

с самим SONAR’ом в части написания своего плагина

  1. В каком состоянии сейчас этот плагин?
#20

Хорошо смотрится.
У апача юнит тесты почти 8 часов идут.
http://nemo.sonarqube.org/dashboard/index/Apache

#21

Абсолютно согласен. Кстати это и был первый шаг НИОКР, называющийся “А оно вообще надо?” :wink:

Кстати, а как именно слово qube должно было мне это намекнуть?

#22

Вот тебе и qube (q cube)