Yaxunit

[kuzja086]

89 Пока черновой вариант, все топорно и костыльно. Хочу сверить концепцию и уточнить некоторые моменты.

Пока остановился на том, что тесты запускаются и отображаются в панельке junit в jenkins на моей машине=) . Дальше буду рефакторить.

1) Сейчас захардкорил скачивание расширения yaxunit. Было несколько идей таких как:

• Скачивать готовое последнее расширение с релизов гитхаба; (Кажется наиболее распространенным)
• Скачивать определенную версию с релизов гитхаба;
• Скачивать исходники и собирать из исходников расширение;
• Может у кого-то тесты будут сразу в расширении yaxunit или ядро будет доработано и оно будет лежать в одном репо с проектом. Как лучше? 2) В какой момент загружать yaxunit и тесты? вроде логично загружать при инициализации базы, прописав дополнительные шаги. А вроде логично уже на этапе тестов все загрузить и запустить (всякие принципы единственности ответственности и т.п.). Пока остановился на втором варианте. 3) Путь для сохранения отчета в junit указывается в конфиг файле, который передается при запуске 1с. Но т.к. агенты могут запускаться как под линукс так и под виндой, то не понятно какой путь указать. Переопределить путь через параметры запуска нельзя, нужно доработать yaxunit. Пока решил остановится на варианте, что конфиг надо собрать динамически, но почему-то не получается сохранить файл, выдает ошибки (нет файла, нет параметров, нет прав) ЧТЯДНТ? Поэтому пока захардкодил конфиг с агентом под виндой. И, как я понимаю, если так делать, то лучше вынести работу с конфигом в отдельный класс?

[nixel2007]

Спасибо большое, погляжу

[kuzja086]

@nixel2007 Не получилось посмотреть? 😊

[nixel2007]

Только из отпуска вышел. Обязательно доберусь на днях.

[ovcharenko-di]

@kuzja086 планируешь доделать? я бы воспользовался

По п.2 лично я поддерживаю твое решение грузить расширение прямо в стейдже, потому что сейчас подключенное расширение YAXUnit может приводить к ошибкам при "обычной" работе, соответственно, оно может мешать bdd и дымовым тестам.

Думаю, что надо поддержать в библиотеке самый "правильный" способ, когда исходники тестов лежат в том же репозитории, что и основная конфигурация, поэтому надо добавить для стейджа 2 параметра:

• cfe - ссылка на cfe (либо оф.релиз на GH, либо ссылка на свою версию)
• extensionName - (необязательный параметр) имя расширения с тестами (или путь?), которое нужно собрать и подключить. если параметр не указан, то считаем, что тесты находятся прямо внутри cfe

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

@nixel2007 есть мысли?

[kuzja086]

@ovcharenko-di Да, планирую закончить. Сейчас жду обратной связи от @nixel2007 😊 Идея с параметрами стейджа мне нравится, например если cfe не заполнен, то качаем из оф. Репо на GH и testPath относительный путь к исходникам расширения с тестами. Если не заполнен, то значит предполагаем, что тесты в ядре.

Есть идеи как быть с путем к отчету junit? На мой взгляд лучше доработать Yaxunit, чтобы через параметры запуска можно было переопределять его. Может еще варианты есть ?

[ovcharenko-di]

@kuzja086 по поводу пути к отчету junit: я считаю, что в библиотеке путь к отчету junit можно просто захардкодить, как это сделано сейчас для шагов bdd и smokeTest. Тогда ожидается, что пользователь библиотеки сам предоставит конфиг, в котором будет указан именно этот путь.

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

[ovcharenko-di]

@kuzja086 я в твоем форке создал PR!

[kuzja086]

@nixel2007 мы готовы))

[ovcharenko-di]

@nixel2007 вот теперь точно готовы)

[ovcharenko-di]

@nixel2007 посмотри, плз

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

[nixel2007]

Superseded by #114