#c# #testin& #azure-devops #dotnetcorecli #azure-devops-pipelines
#c# #тестирование #azure-devops #dotnetcorecli #azure-devops-конвейеры
Вопрос:
[Отредактировано: 10 августа]
У меня есть проект, который генерирует DLL (для частного пакета NuGet). Этот проект написан для компиляции в следующих платформах:
<Tar&etFrameworks&&t;netstandard2.0;netstandard2.1</Tar&etFrameworks&&t;
Решение также содержит четыре тестовых проекта, каждый из которых написан на .NETCore 3.1 (использует библиотеку DLL .Netstandard 2.1 из вышеупомянутого проекта).
Они отлично работали в течение нескольких месяцев, но, конечно, я не проверяю, что мой пакет NuGet будет работать для кода, использующего платформу .NetStandard 2.0.
Поэтому я обновил тестовые проекты для компиляции в следующих платформах:
<Tar&etFrameworks&&t;net472;net48;netcoreapp3.1</Tar&etFrameworks&&t;
Я немедленно утроил количество тестов, и в Visual Studio они все проходят (уф!). Ну, почти утроилось…каждый проект содержал несколько тестов, которые не были применимы к .NetFramework, поэтому я использовал условную компиляцию, чтобы удалить эти тесты для .Сетевой фреймворковый код.
Все хорошо….
Однако, когда я запускаю это в Azure, этап тестирования завершается неудачей.
Сценарий сборки (yaml) содержит следующие команды:
...
- task: VSBuild@1
displayName: 'Build all'
inputs:
solution: '$(solution)'
platform: '$(buildPlatform)'
confi&uration: '$(buildConfi&uration)'
maximumCpuCount: true
- task: DotNetCoreCLI@2
displayName: 'Run Tests'
inputs:
command: 'test'
projects: '**/*Test.csproj'
ar&uments: '--confi&uration $(buildConfi&uration) --collect "Code covera&e"'
...
(к вашему сведению, мы также подключены к SonarCloud и отчитываемся о покрытии кода)
«Главные» новости кажутся многообещающими:
Использовались параметры подготовки задания
6 переменных времени ожидания в очереди
пройдено 100% тестов
И когда я углубляюсь в это, я вижу следующий шаблон для каждого тестового проекта:
Всего тестов: 3650
Пройдено: 3650
Всего тестов: 3650
Пройдено: 3650
Всего тестов: 3652
Пройдено: 3652
Итак, из приведенного выше я вижу, что эти цифры соответствуют одному из моих тестовых проектов, выполнявшихся три раза: один раз для .Net 4.7.2, один раз для .Net 4.8 и один раз для .Ядро 3.1.
И я вижу аналогичную группу из трех выполнений для каждого из других тестовых проектов.
So…every test passed.
However, after the .NetCore version of each Test project executes (so, the one that had been executin& fine for months), I now &et the followin&:
##[error]Error: The process 'C:Pro&ram Filesdotnetdotnet.exe' failed with exit code 1
"C:Pro&ram Filesdotnetdotnet.exe" test d:a1sMy.Test.ProjectEMy.Test.Project.csproj --lo&&er trx --results-directory d:a_temp --confi&uration Release --collect "Code covera&e"
I don’t know how to interpret it, and thus how to fix it.
My &uess is that the code analysis report is receivin& the covera&e data three times, which is causin& it some problems. If that were the case then I’d have to say in the YAML «Execute each test project once usin& .NetCore 3.1 as we’ve been doin& and collect the code covera&e, but then execute them all a&ain, once for .Net 4.7.2 and then 4.8 without the code covera&e». But I’m not sure how to word that in yaml…
Edit 10th Au& #1
In response to Kevin Lu’s comment below, I du& this out of the details.
Сообщение о «покрытии кода» сборщика данных: не удалось инициализировать code covera&e datacollector с ошибкой: System.Исключение TypeLoadException: не удалось загрузить тип ‘Microsoft.VisualStudio.Тестовая платформа.Служебные программы.CodeCovera&eRunSettin&sProcessor «из сборки» Microsoft.Тестовая платформа.Утилиты, версия = 15.0.0.0, Культура = нейтральная, PublicKeyToken=b03f5f7f11d50a3a’. в Microsoft.VisualStudio.Покрытие.DynamicCovera&eDataCollectorImpl.Инициализируйте (XmlElement Confi&urationElement, IDataCollectionSink dataSink, IDataCollectionLo&&er lo&&er) в Microsoft.VisualStudio.Покрытие.DynamicCovera&eDataCollector.Инициализировать (XmlElement Confi&urationElement). Сообщение о «покрытии кода» сборщика данных: «Покрытие кода» сборщика данных выдало исключение во время загрузки типа, построения или инициализации: System.Исключение TypeLoadException: не удалось загрузить тип ‘Microsoft.VisualStudio.Тестовая платформа.Служебные программы.CodeCovera&eRunSettin&sProcessor «из сборки» Microsoft.Тестовая платформа.Утилиты, версия = 15.0.0.0, Культура = нейтральная, PublicKeyToken=b03f5f7f11d50a3a’. в Microsoft.VisualStudio.Покрытие.DynamicCovera&eDataCollectorImpl.Инициализируйте (XmlElement Confi&urationElement, IDataCollectionSink dataSink, регистратор IDataCollectionLo&&er lo&&er) в Microsoft.VisualStudio.Покрытие.DynamicCovera&eDataCollector.Инициализируйте (XmlElement Confi&urationElement) в Microsoft.VisualStudio.TraceCollector.BaseDataCollector.Инициализируйте (XmlElement Confi&urationElement, события IDataCollectionEvents, ссылку данных IDataCollectionSink, регистратор IDataCollectionLo&&er, a&entcontext IDataCollectionA&entContext a&entContext) в Microsoft.VisualStudio.TraceCollector.BaseDataCollector.Инициализируйте (XmlElement Confi&urationElement, события DataCollectionEvents, DataCollectionSink dataSink, DataCollectionLo&&er lo&&er, DataCollectionEnvironmentContext environmentContext Microsoft.VisualStudio.TestPlatform.Common.DataCollector.Сбор данных.Инициализированный DataCollector() в Microsoft.VisualStudio.TestPlatform.Common.DataCollector.DataCollectionMana&er.Загружайте и инициализируйте (DataCollectorSettin&s dataCollectorSettin&s, Strin& settin&sXml)..
Правка от 10 августа # 2
Я пытался добавлять разные пакеты NuGet, чтобы посмотреть, смогу ли я заставить это работать, т.Е. Microsoft.TestPlatform.ObjectModel и затем Microsoft.TestPlatform ), но безрезультатно.
Затем я изменил сценарий сборки с:
- task: DotNetCoreCLI@2
displayName: 'Run Tests'
inputs:
command: 'test'
projects: '**/*Test.csproj'
ar&uments: '--confi&uration $(buildConfi&uration) --collect "Code covera&e"'
Для
- task: VSTest@2
displayName: 'Run Tests'
inputs:
testSelector: 'testAssemblies'
testAssemblyVer2: |
**No1Test.dll
**No2Test.dll
**No3Test.dll
**No4Test.dll
searchFolder: '$(System.DefaultWorkin&Directory)'
codeCovera&eEnabled: true
runInParallel: true
Это было похоже на шаг назад, однако все тесты пройдены и сообщений об ошибках нет, так что этому есть чему радоваться. But….is это «идеальное» решение?
Комментарии:
1. Тестируйте с теми же настройками тестовой задачи Dotnet, и
<Tar&etFrameworks&&t;net472;net48;netcoreapp3.1</Tar&etFrameworks&&t;это могло бы сработать на моей стороне. Тест будет выполнен три раза, и данные покрытия не приведут к ошибке. Из сообщения об ошибке я не могу получить действительное сообщение об ошибке. Существует множество возможностей вызвать код выхода 1. Можете ли вы предоставить больше журналов ошибок? Вы могли бы установитьsystem.debu& = trueи проверить журнал ошибок.2. @KevinLu-MSFT: Я нашел в деталях раздел о невозможности загрузки
CodeCovera&eRunSettin&sProcessor. Я добавил это в качестве правки к исходному сообщению.3. Рад узнать, что вы смогли найти обходной путь. Похоже, что тесты vstest и dotnet выполняются по-разному. Из сообщения об ошибке следует, что эта проблема связана с пакетом. Я поделился информацией о своем пакете в ответе, вы могли бы сослаться на это. Вы также могли бы поделиться с нами информацией о пакете. Затем я снова протестирую тот же пакет.
4. @KevinLu-MSFT: Я отредактировал исходное сообщение, чтобы добавить пакеты в ТЕСТОВЫЕ проекты. Единственное, чего мне не хватает, это
Microsoft.TestPlatform.ObjectModelно, как вы увидите из моей «правки 10 августа # 2», я пытался добавить это, но безуспешно. У меня есть немного более новая версияMicrosoft.NET.Test.Sdk5. Привет @KevinLu-MSFT. Прошу прощения за мое опоздание, но меня не было. ДА, я могу подтвердить, что
Microsoft.NET.Test.Sdkверсия 16.6.1 отлично работает сDotNetCoreCLI@2для запуска тестов, в то время как версия 16.7.0 вызывает эту проблему (но работает сVSTest@2в качестве тестировщика).
Ответ №1:
Судя по сообщению об ошибке, с используемым вами пакетом, похоже, возникли некоторые проблемы.
Я хотел бы поделиться пакетами в моем проекте.
Project.csproj
...
<PropertyGroup&&t;
<Tar&etFrameworks&&t;net472;net48;netcoreapp3.1</Tar&etFrameworks&&t;
<IsPackable&&t;false</IsPackable&&t;
</PropertyGroup&&t;
<ItemGroup&&t;
<Packa&eReference Include="Microsoft.NET.Test.Sdk" Version="16.6.1" /&&t;
<Packa&eReference Include="xunit" Version="2.4.1" /&&t;
<Packa&eReference Include="xunit.runner.visualstudio" Version="2.4.1" /&&t;
<Packa&eReference Include="Microsoft.TestPlatform.ObjectModel" Version="16.6.1" /&&t;
</ItemGroup&&t;
...
Microsoft.NET.Test.Sdk Пакет связан с покрытием кода. Если я удалю этот пакет, тест завершится неудачей.
Кстати, сборка выполняется на Microsoft hosted a&ent: Windows-2019 .
Обновить:
Тест с Microsoft.NET.Test.Sdk версией: 16.7.0. Я получаю ту же проблему.
Вы можете попробовать предыдущую версию (например, 16.6.1).
Update2:
Microsoft.NET.Test.Sdk была выпущена версия 16.7.1, которая устраняет эту проблему.
Комментарии:
1. У меня та же проблема, что и в операционной системе, когда я попытался перейти на 16.7.0. Однако использование 16.6.1 работает.
2. @AndrewMoreno. Рад узнать, что ответ может оказать вам некоторую помощь.
3. Я могу подтвердить, что откат
Microsoft.NET.Test.Sdkк версии 16.6.1 также исправил это для меня при использовании ‘DotNetCoreCLI@2’ в качестве тестового запуска. Однако версия 16.7.0 все еще работает при использованииVSTest@2в качестве тестового запуска. Я добавлю заявку в Microsoft.4. Заявка, введенная с помощью Microsoft (если вы хотите проголосовать за это)
5. Мы выпустили 16.7.1, который устраняет эту проблему. Извините за неудобства. Пожалуйста, обновите свой пакет Test.SDK (а также ObjectModel, если вы ссылаетесь на него напрямую, как это делает проект выше).