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

Прежний вариант 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 / ЗапуститьТестироватьЮнит}    
			ВызватьИсключение ПредставлениеКоманды;
}

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

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

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 / ЗапуститьТестироватьЮнит}    
			ВызватьИсключение ПредставлениеКоманды;
}

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

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

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

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

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

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

1 Симпатия

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

1 Симпатия

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

1 Симпатия

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

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

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

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

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

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

  • и для vanessa-runner
  • и для xunit
1 Симпатия

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

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

1 Симпатия

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

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

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

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

2 Симпатий

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

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

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

3 Симпатий

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

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

1 Симпатия

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

1 Симпатия

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

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

1 Симпатия

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

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

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

1 Симпатия

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

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

1 Симпатия