Как правильно теперь вызвать runner xunit?

add

#1

Прежний вариант runner xunit tests/metadata --ordinaryapp 1 --reportsxunit ГенераторОтчетаJUnitXML{metadata-junit.xml};ГенераторОтчетаAllureXML{allure-results/metadata.xml}

теперь вот так ругается:

ОШИБКА - Ошибка:{Модуль C:\Program Files (x86)\OneScript\lib\vanessa-runner\src\Классы\МенеджерКонфигуратора.os / Ошибка в строке: 174 / Результат работы не равен 0 или 2, а равен Не найден файл статуса }
КРИТИЧНАЯОШИБКА - {Модуль C:\Program Files (x86)\OneScript\lib\vanessa-runner\src\Классы\КомандаТестирование_xUnitFor1C.os / Ошибка в строке: 145 / {Модуль C:\Program Files (x86)\OneScript\lib\vanessa-runner\src\Классы\МенеджерКонфигуратора.os / Ошибка в строке: 179 / ЗапуститьТестироватьЮнит}    
			ВызватьИсключение ПредставлениеКоманды;
}

#2

Мне помогает явное указание --xddExitCodePath. Без этого не работает… Больше того, у меня папка проекта очищалась.
Но вроде как поправили это уже.


#3

Так тоже чот не взлетает:

runner xunit tests/metadata --ordinaryapp 1 --xddExitCodePath ./build/xunit-status.txt --reportsxunit ГенераторОтчетаJUnitXML{metadata-junit.xml};ГенераторОтчетаAllureXML{allure-results/metadata.xml}
[...]
ИНФОРМАЦИЯ - Выполнение команды/действия в режиме 1С:Предприятие завершено.
ОТЛАДКА - Читаю из файла D:\workspace\SBM 1.6.x Empty\build\xunit-status.txt
ОТЛАДКА - файл статуса:
<1>
ОШИБКА - Ошибка:{Модуль C:\Program Files (x86)\OneScript\lib\vanessa-runner\src\Классы\МенеджерКонфигуратора.os / Ошибка в строке: 174 / Результат работы не равен 0 или 2, а равен 1}
КРИТИЧНАЯОШИБКА - {Модуль C:\Program Files (x86)\OneScript\lib\vanessa-runner\src\Классы\КомандаТестирование_xUnitFor1C.os / Ошибка в строке: 145 / {Модуль C:\Program Files (x86)\OneScript\lib\vanessa-runner\src\Классы\МенеджерКонфигуратора.os / Ошибка в строке: 179 / ЗапуститьТестироватьЮнит}    
			ВызватьИсключение ПредставлениеКоманды;
}

#4

В последнем варианте все верно.

Тесты выполнились с ошибками, возвращается статус 1 и выбрасывается исключение.

@Vladislav_Moroz какое поведение ты ожидал?


#6

Думаю, что нужно сохранить совместимость, чтобы можно было вызвать без указания параметра --xddExitCodePath, и чтобы в этом случае исключение не выбрасывалось даже при ошибочных тестах.

Поясню: у меня в сборочной линии несколько стадий, в которых запускается runner xunit. Обидно, если при нескольких падающих тестах будет падать вся линия, когда эти ошибки в тестах не препятствуют прогону остальных тестов.


#7

согласен. создал спец.ишуз для решения


#8

@Vladislav_Moroz @KrapivinAndrey Исправлено в ветке девелоп.


#9

Выпущен релиз 1.3.0 с исправлением нескольких проблем


#10

Спасибо за оперативное исправление!

Пользуясь случаем, ещё один вопрос. Изучаю сейчас https://github.com/silverbulleters/add/issues/75 и пытаюсь понять, должен ли путь к журналу передаваться в параметрах вызова xddTestRunner.epf?


#11

Путь к лог-файлу выполнения теперь задается в конфиг-файле аналогично bdd-файлам настройки
А у тебя, похоже, файл настройки не задан, в vanessa-runner подставляется путь к файлу по умолчанию и настройки берутся по умолчанию

но остается вопрос, на который я пока не знаю ответа:
знает ли xddTestRunner о пути к лог-файлу по умолчанию, если в ком.строку его запуска не передан json-файл конфигурации :frowning:

Для быстрого решения предлагаю начать использовать json-файл и передавать его через параметр --xddconfig в vanessa-runner

Примеры json-файлов есть в каталоге tools/json

  • и для vanessa-runner
  • и для xunit

#12

Да, xddTestRunner не знает об этом пути, т.к. этой информации ему взять негде.

В итоге для работы с лог-файлом выполнения остается использовать json-файл настройки и и передавать его через xddconfig


#13

Ты знаешь что я подумал в качестве идеи, нужен плагин помошник создания, редактирования конфигурационных файлов, типа формы

“Помошник создания и редактирования конфигурации для сервера сборок”, который

  • проверит правильность - что например не используются прямые пути, а только относительные
  • проверит что параметры сохранены под управлением git репозитория
  • прочее интересное

При наличии такого помощника будет быстрей адаптация. А то сейчас получается что необходимо знать магические параметры, которые еще и плохо задокументированны :wink:


#14

@lustin Отличная мысль.

И как раз буквально сегодня в метро я закончил первое приближение к такому инструменту - сделал форму для настройки дымовых тестов.

Будет в ближайшем релизе, который я выпущу для вебинара по ADD в понедельник 16.07


#15

Как это негде? А выше же на моём скриншоте передаётся в ПараметрЗапуска workspaceRoot (кстати, из-за того что передаётся без кавычек, он у меня в итоге всё лепит в одну папку в один лог).
И вот же ещё такой коммит про ключ --xdddebug https://github.com/silverbulleters/vanessa-runner/commit/8efa0b676c4378e7ea63fd7ed47ba09379c9c660


#16

Да, да, да - хотеть gui для дымовых. Я задолбался на последнем внедрении. 6 часов настраивал - а типовая падает и падает (ремарка для Влад НЕ УНФ)


#17

@Vladislav_Moroz Расшифруй, я не понял


#18

Ага, теперь я тебя понял.
Получается, что раннер вычисляет путь к лог-файлу по умолчанию (build/) , но не отдает эту информацию в xddTestRunner :frowning:

Да, нужно исправить.


#19

Неточно,
все-таки перефразирую:
xddTestRunner

  • в случае передачи каталога проекта
  • и отсутствия указания json-файла настройки (xddconfig)
    должен писать свой лог в build/xddonline.txt (путь по умолчанию)

Возможно, лучше добавить ключ командной строки --onlinelog


#20

А чем этот ключ будет отличаться от --xdddebug?


#21

–xdddebug это просто показ отладочных сообщений, а не только штатных от раннеров
–onlinelog, возможно, указание файла лога тестирования