gifts2017

Анализ результатов юнит-тестирования

Опубликовал Роман Уничкин (unichkin) в раздел Программирование - Инструментарий

Не так давно попал на ситуацию, когда непонятно из-за какого коммита упал тест. Разработал для себя инструмент для выявления тех тестов, которые упали именно после моих правок.

Страница проекта x-Unit на гитхабе: xUnitFor1C - простой и мощный фреймворк для тестирования в 1С

Публикация:  xUnitFor1C - набор инструментов для выполнения тестирования


Сперва необходимо взять два cf: первый это снимок до коммита, второй - соответственно после. Далее нужно прогнать обе конфы через тесты, и сравнить результаты между собой. Исключив повторяющиеся ошибки,  получим именно те тесты, которые упали после коммита. 

Как запустить автоматическое тестирование в пакетном режиме написано здесь: запуск тестов из командной строки и получение файлов результатов

В ролике показаны произвольные данные - для демонстрации функционала На деле тестов было очень много, сравнивать их вручную - неблагодарная задача.

Отчет можно использовать не только для анализа сравнения, но и просто как отчет по xml-результату теста.

Demo1.xml - результат теста cf до коммита
Demo2.xml - результат теста cf после коммита
1) Формирование отчета по результату тестирования Demo1.xml
2) Формирование отчета по результату тестирования Demo2.xml
3) Сравнение Demo1 и Demo2, вывод различий
4) Изменение настроек вывода отчета

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Отчет по результату пакетного теста xUnit
.erf 17,67Kb
28.11.16
0
.erf 1.1 17,67Kb 0 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Артур Аюханов (artbear) 30.11.16 14:03
Интересно.
А вот если реализовать прогон тестов на билд-сервере (реализовав CI), тогда возможно различия анализировать для любого коммита в автоматическом режиме.
Например, на билд-сервере всегда можно увидеть, когда (на каком коммите) начал падать любой тест, какая ошибка тестирования и прочую информацию.

Рекомендую именно этот режим (использование CI и билд-сервера) использовать.

И потери времени меньше будет - не нужно будет дважды запускать прогон тестов.

PS ИМХО из статьи не совсем понятно, какой инструмент используется в качестве инструмента тестирования.
Предлагаю явно указать xUnitFor1C со ссылкой на главную страницу проекта на Гитхабе.
2. Роман Уничкин (unichkin) 30.11.16 17:23
"А вот если реализовать прогон тестов на билд-сервере"
- так и работает. Но вот выдало мне около 20 упавших тестов, т.е. выдаются ВСЕ тесты, которые падают после моего коммита. Но не факт что все они - из-за него. Вот отсюда и родился отчет.

"Предлагаю явно указать xUnitFor1C со ссылкой на главную страницу проекта на Гитхабе."
- Укажу, раз Вы не против) Сам не решился, а то пахнет саморекламой за чужой счет.
3. Евгений Сосна (pumbaE) 30.11.16 17:57
Ну так в Jenkins как раз и выдается +2 new или же -1 сломаных тестов, по отношению к предыдущей сборки.
4. Роман Уничкин (unichkin) 30.11.16 18:15
Не знаю, возможно что-то сглючнуло. Но факт - мне выдался список тестов, которые падали до моего коммита. Я и полез сравнение лепить, чтобы в этом убедиться. Недавно также была ситуация, когда локально все тесты прошли, а сборщик выдавал ошибку. Так что 100% уверенности в нем нет, для мутных случаев держу этот отчет под рукой.
5. Артур Аюханов (artbear) 01.12.16 18:40
(4) >мне выдался список тестов, которые падали до моего коммита

ИМХО это вполне возможно, если был более ранний коммит, в результате которого начали падать тесты, и эти падения не исправили :)
Т.е. на билд-сервере нужно смотреть, когда появилось падение данного теста, на каком коммите.

Т.е. дифф падений на билд-сервере все-таки возможен.

ЗЫ кому-нибудь приходят уведомления о комментариях в почту с ИС ??
6. Роман Уничкин (unichkin) 01.12.16 20:12
Приходят, только поздно. ~3 часа.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа