Спасибо, что уделили время. Замечания учту при написании следующих статей.
Проблема с набором записей «Лидой» не решена. Мы просто создали сущности заранее и сохранили в виде образа виртуальной машины и перед запуском разворачиваем его.
Ложные срабатывания я распределил по типам и исправлял их в несколько этапов.
Я написал свою реализацию создания JUnit xml по описанию стандарта. Схему не использовал. В процессе выполнения магнитофон собирает необходимые данные о выполненном тесте и просто добавляет узел с данными о тесте (testcase) в соответствующую группу тестов (testsuite). Если была ошибка, то к тесту добавляется еще узел с описанием ошибки (failure). После завершения получается валидный JUnit xml файл.
Настроили Jenkins, чтобы он на удаленной машине включал магнитофон, синхронизировал тесты, запускал выполняемый файл, который воспроизводит тесты, перенаправлял вывод в файл лога и указывал путь для файла отчета в JUnit. Затем Jenkins копирует к себе файл JUnit и показывает результат.
Насколько я понимаю, vcr для тестирования фронтенда. Магнитофон предназначен для тестирования бекэнда. Он делает все запросы напрямую в API приложения, не через браузер.
Проблема с набором записей «Лидой» не решена. Мы просто создали сущности заранее и сохранили в виде образа виртуальной машины и перед запуском разворачиваем его.
Ложные срабатывания я распределил по типам и исправлял их в несколько этапов.
execute /usr/local/mgr5/sbin/mgrctl -m ispmgr test.synchronize 2>&1 | ( grep ERROR || exit 0 && exit 1 ) >> /root/ispmgr-int-player.log 2>&1/usr/local/mgr5/sbin/dotest --branch master --junit -o ispmgr-int-player.xml /usr/local/mgr5/var/ispmgr.test/ >> /root/ispmgr-int-player.log 2>&1
File successfully received /usr/local/mgr5/ispmgr-int-player.xml