Параллельный запуск тестов с использованием VSTest не работает

ProgramBox

Параллельный запуск тестов с использованием VSTest не работает

Post author:admin
Запись опубликована:10 апреля, 2023
Post category:Вопросы по программированию

#devops #vstest #parallel-testing

#devops #vstest #параллельное тестирование

Вопрос:

Я пытаюсь реализовать параллельное тестирование с использованием задачи VSTest, как указано в статье ниже. https://learn.microsoft.com/en-us/azure/devops/pipelines/test/parallel-testing-vstest?view=azure-devops

Краткое описание того, что я делаю:

У меня есть два автономных агента, установленных на одном сервере. Когда я запускаю тесты с одним параметром агента (любым из них), он выполняется без каких-либо проблем. Но когда я применяю мультиагентную опцию либо с а) простым разделением на основе количества тестов и агентов, либо б) разделением на основе тестовых сборок, я получаю приведенную ниже ошибку. ##[ошибка]Фрагмент типа «Обнаружение» «Прерван» из-за ошибки: System.Исключение: из указанных источников тестов не обнаружено тестов.

Сообщение об ошибке

Заранее спасибо, Удайя Бхаскар.

1. Можете ли вы показать свой YAML для части тестирования? В частности, как вы загружаете, а затем загружаете свои сборки? Возможно, он не находит ничего для тестирования, потому что в агенте он разветвляется на ваши тестовые сборки, которые не существуют.

2. Привет @T2PS, ниже приведены оба YAMLS, надеюсь, этого достаточно. Опубликовать артефакт YAML шаги: — задача: Опубликовать построенные артефакты@1 имя_дисПлея: ‘Опубликовать артефакт: пакеты’ входные данные: Путь к публикации: ‘$(Build. ArtifactStagingDirectory)Packages’ ArtifactName: Пакеты загружают артефакты сборки YAML: шаги: — задача: DownloadBuildArtifacts@0 DisplayName: ‘Загрузить артефакты сборки’ входные данные: artifactName: Пакеты.

3. Привет @T2Ps, к вашему сведению, мой источник управления — «TFVC». Мои конвейеры сборки используют классический редактор. Вот скриншоты YAML. Загрузить артефакт , Download_Build_Artifacts

4. Извините, я забыл спросить еще одну деталь: YAML для того, как вы вызываете тесты?

5. Привет @T2PS Вот VSTest YAML сценарий YAML слишком длинный, чтобы поместиться здесь, пожалуйста, дайте мне знать, если sript необходим, тогда я отправлю в двух частях.. Спасибо.

Ответ №1:

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

Задача PublishBuildArtifacts имеет путь по умолчанию $(Build.ArtifactStagingDirectory) ; вы переопределили его на $(Build.ArtifactStagingDirectory)Packages . Если этот параметр установлен правильно при просмотре артефактов для сборки, вы должны иметь возможность загружать свои тестовые сборки и их зависимости, которые были загружены из этого расположения.
Задача DownloadBuildArtifacts имеет значение по умолчанию, downloadPath значение $(System.ArtifactsDirectory) которого в представлении YAML указывает, что вы не переопределили.
Задача VSTest имеет значение по умолчанию searchPath $(System.DefaultWorkingDirectory) ; представление YAML показывает, что вы установили это значение $(Agent.BuildDirectory)Bin .

Точное поведение здесь может зависеть от того, как ваши агенты были настроены для своих дисковых путей. $(Agent.BuildDirectory) обычно это один из пронумерованных подкаталогов базового рабочего пути агента. Интересно, что, хотя в DownloadBuildArtifacts документации указано $(System.ArtifactsDirectory) , что это значение по умолчанию, оно не отображается в текущем списке предопределенных переменных; если это действительно относится к $(Build.ArtifactStagingDirectory) , по умолчанию используется «numbered_build_subdirectory a».

Поскольку ваш путь поиска теста расширится до «numbered_build_subdirectory Bin», я ожидаю, что (при условии, что файлы публикуются правильно) они загружаются в местоположение, которое находится за пределами пути поиска, на который нацелена тестовая задача, что объясняет, почему тесты не найдены.

Я бы предложил изменить пути загрузки и поиска для DownloadBuildArtifacts и VSTest , чтобы они были одинаковыми и относились к базовому каталогу, например: $(Agent.BuildDirectory)Tests (или что-то еще, подходящее для вашего конвейера).

1. Привет @T2PS, спасибо за подробный ответ. Здесь есть одна загвоздка, с теми же переменными пути к диску, приведенными ниже, сценарий с одним агентом работает хорошо . Я пробовал с обоими агентами по отдельности. $(Сборка. ArtifactStagingDirectory)Packages $(System. ArtifactsDirectory) $(Агент. BuildDirectory) Bin Я провел еще один эксперимент: вручную проверил путь к динамическому диску ( C:DynamicsSDKVSOAgent_work5Bin ) и запустите vstest.console.exe вручную для тестовой библиотеки DLL. На удивление, это сработало хорошо . Вопрос: Когда мы используем мультиагент, я надеюсь, что тот же vstest.console отвечает за запуск tst.

2. Да, я бы ожидал, что код будет таким же. Разница в сценариях заключается в том, что в single agent вы можете оставлять файлы из вашей первоначальной сборки в Bin, и именно они подбираются тестовой задачей. В параллельном сценарии тестовые файлы существуют только из-за загрузки артефакта (особенно, если рабочий каталог очищается перед запуском задания), поэтому путь, по которому они загружаются, должен совпадать с тем, где vstest.console.exe будет выполнен поиск. Кроме того, когда сборка завершена (пройдена или не выполнена), можете ли вы загрузить свои двоичные файлы из списка артефактов WebUI?

3. ПРИВЕТ @T2PS, действительно ценю ваше ценное продолжение этого. Я попытался изменить пути к переменным в соответствии с вашим предложением, к сожалению, возникает та же ошибка. Фактически все эти переменные указывают только на одно и то же местоположение (Agent. Buildдиректория и система. ArtifactsDirectory). Отвечая на ваш второй вопрос, да, я могу получить доступ к загрузке двоичных файлов по ссылке artifucats. Возможно ли на следующей неделе провести один общий доступ к экрану, чтобы вы могли правильно направлять. Заранее спасибо.