Создание файла конфигурации Runsettings во время задачи сборки VSTS «Тест Visual Studio» - PullRequest
Новая
       45

Создание файла конфигурации Runsettings во время задачи сборки VSTS «Тест Visual Studio»

1 голос
/ 12 июня 2019

Для начала моя основная проблема заключается в том, что в Visual Studio 2017 различаются выходы покрытия кода и задача конвейера сборки VSTS (Azure Dev Ops) "Visual Studios Test".

При анализе покрытия кода в визуальных студияхЯ использую 2017, для тестов моего решения кажется, что во время процесса он создает на лету временный файл конфигурации runsettings и использует его при вызове процесса vstest.console.exe.

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

<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <DataCollector uri="datacollector://microsoft/unittestisolation/1.0" assemblyQualifiedName="Microsoft.VisualStudio.TraceCollector.UnitTestIsolationDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" friendlyName="UnitTestIsolation">
    <Configuration>
    </Configuration>
  </DataCollector>
  <DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector">
    <Configuration>
      <CoverageFileName>Coverage 2019-06-11 14_30_31.coverage</CoverageFileName>
      <CodeCoverage>
        <ModulePaths>
          <Exclude>
            <ModulePath>.*CPPUnitTestFramework.*</ModulePath>
          </Exclude>
          <Include>
            <ModulePath>.*\\<MyNamespace>\.API\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.ACL\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.Services\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.API\.Contracts\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.Services\.Contracts\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.ACL\.Contracts\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.Services\.UnitTests\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.ACL\.UnitTests\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.PaymentSystem\.Util\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.MerchantContracts\.Clover\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.UnitTests\.Data\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.Data\.EF\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.Domain\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.Domain\.UnitTests\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.Core\.NuGetResources\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.MerchantContracts\.Mercury\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.Processor\.exe</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.Processor\.Testing\.exe</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.Processor\.UnitTests\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.MerchantContracts\.Mindbody\.dll</ModulePath>
            <ModulePath>.*\\<MyNamespace>\.API\.UnitTests\.dll</ModulePath>
          </Include>
        </ModulePaths>
    ... etc
</RunSettings>

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

<MyNamespace>.infrastructure.libraries.dll
<MyNamespace>.infrastructure.libraries.domain.dll
<MyNamespace>.infrastructure.libraries.logging.dll
<MyNamespace>.infrastructure.libraries.webapi.dll
<MyNamespace>.acl.dll
<MyNamespace>.acl.unittests.dll
<MyNamespace>.api.contracts.dll
<MyNamespace>.domain.dll
<MyNamespace>.domain.unittests.dll
<MyNamespace>.merchantcontracts.clover.dll
<MyNamespace>.merchantcontracts.mercury.dll
<MyNamespace>.merchantcontracts.mindbody.dll
<MyNamespace>.processor.unittests.dll
<MyNamespace>.services.contracts.dll
<MyNamespace>.services.dll
<MyNamespace>.services.unittests.dll
<MyNamespace>.unittests.data.dll

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

Мои настройки выполнения. 

<RunSettings>
<DataCollectionRunSettings>
    <DataCollectors>
        <DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
            <Configuration>
                <CodeCoverage>
                </CodeCoverage>
            </Configuration>
        </DataCollector>
    </DataCollectors>
</DataCollectionRunSettings>
</RunSettings>

Сгенерированное покрытие кода соответствует покрытию ранее, но затем мы также получаем дополнительные сторонние / нежелательные dll. 

fluentassertions.core.dll
fluentassertions.dll
moq.dll
nunit3.testadapter.dll

Теперь в VSTS задача «Visual Studio Test» без какой-либо настройки runsettings включает в себя дополнительные сторонние dll, перечисленные выше.В отличие от Visual studio 2017, он не создает конфигурацию runsettings на лету, чтобы отфильтровать их.Вместо этого мне приходится вручную создавать конфигурацию набора настроек и включать ее в свой репозиторий, чтобы использовать ее в задаче конвейера сборки.

Основная проблема здесь - это ремонтопригодность.В долгосрочной перспективе я не хочу лично управлять этим файлом и должен помнить, что нужно обновлять его каждый раз, когда я добавляю другой проект, который необходимо получить.Я мог бы сделать путь к модулю более общим, поэтому он использует базу dll для части имени dll. 

<ModulePath>.*\\<MyNamespace>.*\.dll</ModulePath>

Это все еще оставляет место для ошибки.Мне просто кажется глупым, что мне нужно вручную настроить это, когда визуальные студии делают это в фоновом режиме автоматически.

Я надеялся, что кто-то узнает, как сгенерировать покрытие кода в VSTS, используя тот же процессчто Visual Studio делает так, что создает конфигурацию runsettings, используя проекты в решении для фильтрации нежелательных dll-тестов.

...