Configurar testes de unidade usando um arquivo .runsettings

Artigo
02/04/2025

Um arquivo de .runsettings pode ser usado para configurar como os testes de unidade estão sendo executados. Por exemplo, ele pode ser usado para alterar a versão do .NET na qual os testes são executados, o diretório para os resultados do teste ou os dados coletados durante uma execução de teste. Um uso comum de um arquivo .runsettings é personalizar a análise de cobertura de código.

Os arquivos runsettings podem ser usados para configurar testes executados a partir da linha de comando , no IDE ou em um fluxo de trabalho de build usando os Planos de Teste do Azure ou o Servidor do Azure DevOps (anteriormente conhecido como TFS (Team Foundation Server).

Os arquivos runsettings são opcionais. Se você não precisar de nenhuma configuração especial, não será necessário ter um arquivo .runsettings.

Criar um arquivo de configurações de execução e personalizá-lo

Adicione um arquivo de configurações de execução à sua solução. No do Gerenciador de Soluções, no menu de atalho da solução, escolha Adicionar>Novo Iteme selecione Arquivo XML. Salve o arquivo com um nome como test.runsettings.

Se você não vir todos os modelos de item, escolha Mostrar Todos os Modelose escolha o modelo de item.

Dica

O nome do arquivo não importa, contanto que você use a extensão .runsettings.
Adicione o conteúdo do arquivo de exemplo *.runsettings de e, em seguida, personalize-o de acordo com suas necessidades, conforme descrito nas seções a seguir.
Especifique o arquivo *.runsettings que você deseja usar por meio de um dos seguintes métodos:
- Visual Studio IDE
- Linha de comando
- Crie um fluxo de trabalho usando o Azure Test Plans ou o Azure DevOps Server (conhecido anteriormente como TFS – Team Foundation Server).
Execute os testes de unidade para usar as configurações de execução personalizadas.

Se você quiser desativar e ativar as configurações personalizadas no IDE, selecione ou desmarque o arquivo no menu Teste.

Dica

Você pode criar mais de um .runsettings arquivo em sua solução e selecionar um como o arquivo de configurações de teste ativo, conforme necessário.

Especificar um arquivo de configurações de execução no IDE

Os métodos disponíveis dependem da sua versão do Visual Studio.

Visual Studio 2019 versão 16.4 e posterior

Há três maneiras de especificar um arquivo de configurações de execução no Visual Studio 2019 versão 16.4 e posterior.

Autodetectar as configurações de execução
definir manualmente as configurações de execução
Definir uma propriedade de build

Autodetectar o arquivo de configurações de execução

Nota

Isso só funcionará para um arquivo chamado .runsettings.

Para fazer a detecção automática do arquivo de configurações de execução, coloque-o na raiz da solução.

Se a detecção automática de arquivos de configurações de execução estiver habilitada, as configurações neste arquivo serão aplicadas em todos os testes executados. Você pode ativar a detecção automática de arquivos runsettings usando dois métodos:

Selecione Ferramentas>Opções>Testar>Detectar arquivos runsettings automaticamente
Selecione Testar>Definir configurações de execução>Detectar arquivos runsettings automaticamente

Selecione manualmente o arquivo de configurações de execução

No IDE, selecione Testar>Definir Configurações de Execução>Selecione runsettings Arquivo runsettings em toda a solução e, em seguida, selecione o arquivo .runsettings.

Esse arquivo substitui o arquivo .runsettings na raiz da solução, se houver, e é aplicado em todos os testes executados.
Essa seleção de arquivo só persiste localmente.

Selecione o menu de arquivo runettings em toda a solução de teste no Visual Studio

Definir uma propriedade de compilação

Adicione uma propriedade de build a um projeto por meio do arquivo de projeto ou de um arquivo Directory.Build.props. O arquivo de configurações de execução de um projeto é especificado pela propriedade RunSettingsFilePath.

No momento, há suporte para configurações de execução no nível do projeto em projetos C#, VB, C++e F#.
Um arquivo especificado para um projeto substitui qualquer outro arquivo de configurações de execução especificado na solução.
essas propriedades do MSBuild podem ser usadas para especificar o caminho para o arquivo runsettings.

Exemplo de especificação de um arquivo de .runsettings para um projeto:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <RunSettingsFilePath>$(MSBuildProjectDirectory)\example.runsettings</RunSettingsFilePath>
  </PropertyGroup>
  ...
</Project>

Visual Studio 2019 versão 16.3 e anterior

Para especificar um arquivo de configurações de execução no IDE, selecione Testar>Selecionar Arquivo de Configurações. Navegue até o arquivo .runsettings e selecione-o.

Selecione o menu de arquivo de configurações de teste no Visual Studio 2019

O arquivo aparece no menu Teste e você pode selecioná-lo ou desmarcá-lo. Quando estiver marcado, o arquivo de configurações de execução se aplicará sempre que você selecionar Analisar Cobertura de Código.

Especificar um arquivo de configurações de execução da linha de comando

Para executar testes na linha de comando, use vstest.console.exee especifique o arquivo de configurações usando o parâmetro /Settings.

Abra Prompt de Comando do Desenvolvedor para Visual Studio.

Insira um comando semelhante a:

vstest.console.exe MyTestAssembly.dll /EnableCodeCoverage /Settings:CodeCoverage.runsettings

vstest.console.exe --settings:test.runsettings test.dll

Para obter mais informações, consulte VSTest.Console.exe, opções de linha de comando,.

O arquivo *.runsettings

O arquivo *.runsettings é um arquivo XML que contém diferentes elementos de configuração dentro do elemento RunSettings. As seções a seguir detalham os diferentes elementos. Para obter um exemplo completo, consulte exemplo de arquivo *.runsettings.

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <!-- configuration elements -->
</RunSettings>

Cada um dos elementos de configuração é opcional porque tem um valor padrão.

Elemento RunConfiguration

<RunConfiguration>
    <MaxCpuCount>1</MaxCpuCount>
    <ResultsDirectory>.\TestResults</ResultsDirectory>
    <TargetPlatform>x86</TargetPlatform>
    <TargetFrameworkVersion>net6.0</TargetFrameworkVersion>
    <TestAdaptersPaths>%SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar</TestAdaptersPaths>
    <TestCaseFilter>(TestCategory != Integration) &amp; (TestCategory != UnfinishedFeature)</TestCaseFilter>
    <TestSessionTimeout>10000</TestSessionTimeout>
    <TreatNoTestsAsError>true</TreatNoTestsAsError>
</RunConfiguration>

O elemento RunConfiguration pode incluir os seguintes elementos:

Nó	Padrão	Valores
MaxCpuCount	1	O nome da opção diferencia maiúsculas de minúsculas e é fácil de digitar incorretamente como MaxCPUCount. Essa configuração controla o nível de paralelismo no nível do processo. Use 0 para habilitar o paralelismo máximo no nível do processo. Essa configuração determina o número máximo de DLLs de teste ou outros contêineres de teste que podem ser executados em paralelo. Cada DLL será executada em seu próprio processo testhost e será isolada no nível do processo dos testes em outras DLLs de teste. Essa configuração não força os testes em cada DLL de teste a serem executados em paralelo. Controlar a execução paralela em uma DLL (no nível do thread) fica a cargo de frameworks de teste como MSTest, XUnit ou NUnit. O valor padrão é `1`, o que significa que apenas um testhost é executado ao mesmo tempo. Um valor especial `0` permite tantos testhosts quanto você tiver de processadores lógicos (por exemplo, 6, para um computador com seis núcleos físicos sem multithreading, ou 12, para um computador com seis núcleos físicos com multithreading). O número de DLLs distintas na execução determina o número real de testhosts iniciados.
ResultsDirectory		O diretório em que os resultados do teste são colocados. O caminho é relativo ao diretório que contém o arquivo .runsettings.
TargetFrameworkVersion	net40 ou netcoreapp1.0	Omita toda essa marca para detectar automaticamente. Essa configuração define a versão da estrutura ou a família da estrutura a ser usada para executar testes. Os valores aceitos são qualquer moniker de estrutura, como `net48`, `net472`,`net6.0`, `net5.0`, `netcoreapp3.1`, `uap10.0` ou qualquer nome de estrutura completa válido, como`.NETFramework,Version=v4.7.2` ou `.NETCoreApp,Version=v6.0.0`. Para compatibilidade retroativa, `Framework35`, `Framework40`, `Framework45`, `FrameworkCore10`, `FrameworkUap10` são aceitos, ou seja, (`net35`, `net40`, `net45`, `netcoreapp1.0` e `uap10.0`, respectivamente). Todos os valores diferenciam maiúsculas de minúsculas. O valor fornecido é usado para determinar o provedor de runtime de teste a ser usado. Cada provedor de runtime de teste deve respeitar a família de estruturas a ser usada, mas pode não respeitar a versão exata da estrutura: Para o .NET Framework 4.5.1 – 4.8, um testhost criado com a versão exata especificada é usado. Para valores fora desse intervalo, o testhost do .NET Framework 4.5.1 é usado. Para o .NET, o `<TargetFramework>` do projeto de teste (ou mais precisamente `runtimeconfig.json`) determina a versão real. Para UWP, o aplicativo de projeto de teste é um testhost por si só e determina a versão real da UWP usada. Omita o elemento `TargetFrameworkVersion` do arquivo .runsettings para determinar automaticamente a versão da estrutura dos binários criados. Ao serem detectadas automaticamente, todas as estruturas de destino são unificadas em uma única estrutura comum. Quando uma versão diferente da mesma família de estrutura de destino é encontrada, a versão mais recente é escolhida (por exemplo, net452, net472, net48 = net48). Para o executor do .NET Framework (no Visual Studio ou vstest.console.exe na linha de comando do Desenvolvedor), a estrutura de destino comum é net40. Para o executor do .NET (teste dotnet + DLLs), a estrutura de destino comum é definida como netcoreapp1.0.
TargetPlatform	x86	Omita toda essa marca para detectar automaticamente. Essa configuração define a arquitetura a ser usada para executar testes. Os valores possíveis são `x86`, `x64`, `ARM`, `ARM64`, `S390x`. Ao detectar automaticamente, a arquitetura para DLLs AnyCPU pode ser diferente com base no executor. Para o executor do .NET Framework (no Visual Studio ou vstest.console.exe na linha de comando do Desenvolvedor), o padrão é x86. Para o executador do .NET (dotnet test), o padrão é usar a arquitetura do processo atual.
TreatTestAdapterErrorsAsWarnings	falso	falso, verdadeiro
TestAdaptersPaths		Um ou mais caminhos para o diretório em que os TestAdapters estão localizados
TestCaseFilter		Uma expressão de filtro no formato <propriedade><operador><valor>[\|&<Expressão>]. O operador booliano & deve ser representado pela entidade HTML &. Expressões podem ser colocadas entre parênteses. Para obter uma sintaxe detalhada da estrutura das expressões, consulte vstest/docs/filter.md.
TestSessionTimeout		Permite que os usuários encerrem uma sessão de teste quando ela excede um determinado tempo limite, especificado em milissegundos. A definição de um tempo limite garante que os recursos sejam bem consumidos e que as sessões de teste sejam restritas a um tempo definido. A configuração está disponível no Visual Studio 2017 versão 15.5 e posterior.
DotnetHostPath		Especifique um caminho personalizado para o host dotnet usado para executar o testhost. É útil quando você está criando seu próprio dotnet, por exemplo, ao criar o repositório dotnet/runtime. Especificar essa opção ignora a busca por testhost.exee força o uso de testhost.dll.
TreatNoTestsAsError	falso	verdadeiro ou falso Especifique um valor booliano, que define o código de saída quando nenhum teste é descoberto. Se o valor for `true` e nenhum teste for descoberto, um código de saída diferente de zero será retornado. Caso contrário, retorna-se zero.

Elemento DataCollectors (adaptadores de dados de diagnóstico)

O elemento DataCollectors especifica as configurações dos adaptadores de dados de diagnóstico. Os adaptadores de dados de diagnóstico coletam informações adicionais sobre o ambiente e o aplicativo em teste. Cada adaptador tem configurações padrão e você só precisa fornecer configurações se não quiser usar os padrões.

<DataCollectionRunSettings>
  <DataCollectors>
    <!-- data collectors -->
  </DataCollectors>
</DataCollectionRunSettings>

Coletor de dados CodeCoverage

O coletor de dados de cobertura de código cria um log das partes do código do aplicativo que foram utilizadas no teste. Para obter informações detalhadas sobre como personalizar as configurações de cobertura de código, consulte Personalizar a análise de cobertura de código.

<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>
      <ModulePaths>
        <Exclude>
          <ModulePath>.*CPPUnitTestFramework.*</ModulePath>
        </Exclude>
      </ModulePaths>

      <UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
      <AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
      <CollectFromChildProcesses>True</CollectFromChildProcesses>
      <CollectAspDotNet>False</CollectAspDotNet>
    </CodeCoverage>
  </Configuration>
</DataCollector>

Coletor de dados VideoRecorder

O coletor de dados de vídeo captura uma gravação de tela quando os testes são executados. Essa gravação é útil para solucionar problemas de testes de interface do usuário. O coletor de dados de vídeo está disponível no Visual Studio 2017 versão 15.5 e posterior. Para obter um exemplo de configuração desse coletor de dados, confira o Arquivo de exemplo *.runsettings.

Para personalizar qualquer outro tipo de adaptadores de dados de diagnóstico, use um arquivo de configurações de teste .

Culpar o coletor de dados

Essa opção pode ajudá-lo a isolar um teste problemático que causa uma falha no host de teste. A execução do coletor cria um arquivo de saída (Sequence.xml) no TestResults, que captura a ordem de execução do teste antes da falha.

Você pode executar o comando blame em três modos diferentes:

Modo de arquivo de sequência: para criar um arquivo com a lista de testes até o travamento
Modo de despejo de memória: para criar um despejo quando o testhost falha
Modo de despejo de travamento: para criar um despejo quando o teste não é concluído antes do tempo limite especificado

A configuração XML deve ser colocada diretamente no nó <RunSettings>:

<RunSettings>
  <RunConfiguration>
  </RunConfiguration>
  <LoggerRunSettings>
    <Loggers>
      <Logger friendlyName="blame" enabled="True" />
    </Loggers>
  </LoggerRunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <!-- Enables blame -->
      <DataCollector friendlyName="blame" enabled="True">
        <Configuration>
          <!-- Enables crash dump, with dump type "Full" or "Mini".
          Requires ProcDump in PATH for .NET Framework. -->
          <CollectDump DumpType="Full" />
          <!-- Enables hang dump or testhost and its child processes 
          when a test hangs for more than 10 minutes. 
          Dump type "Full", "Mini" or "None" (just kill the processes). -->
          <CollectDumpOnTestSessionHang TestTimeout="10min" HangDumpType="Full" />
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

ParâmetrosDeExecuçãoDeTeste

<TestRunParameters>
    <Parameter name="webAppUrl" value="http://localhost" />
    <Parameter name="docsUrl" value="https://learn.microsoft.com" />
</TestRunParameters>

Os parâmetros de execução de teste fornecem uma maneira de definir variáveis e valores que estão disponíveis para os testes em tempo de execução. Acesse os parâmetros usando a propriedade MSTest TestContext.Properties (ou a TestContext NUnit):

public TestContext TestContext { get; set; }

[TestMethod] // [Test] for NUnit
public void HomePageTest()
{
    string appUrl = TestContext.Properties["webAppUrl"];
}

Para usar parâmetros de execução de teste, adicione uma propriedade TestContext pública à sua classe de teste.

Elemento LoggerRunSettings

A seção LoggerRunSettings define um ou mais registradores a serem usados para a execução do teste. Os registradores mais comuns são console, Arquivo de Resultados de Teste do Visual Studio (trx) e arquivo HTML.

<LoggerRunSettings>
    <Loggers>
      <Logger friendlyName="console" enabled="True">
        <Configuration>
            <Verbosity>quiet</Verbosity>
        </Configuration>
      </Logger>
      <Logger friendlyName="trx" enabled="True">
        <Configuration>
          <LogFileName>foo.trx</LogFileName>
        </Configuration>
      </Logger>
      <Logger friendlyName="html" enabled="True">
        <Configuration>
          <LogFileName>foo.html</LogFileName>
        </Configuration>
      </Logger>
    </Loggers>
  </LoggerRunSettings>

Elemento MSTest

Essas configurações são específicas para o adaptador de teste que executa métodos de teste que têm o atributo TestMethodAttribute.

<MSTest>
    <MapInconclusiveToFailed>True</MapInconclusiveToFailed>
    <CaptureTraceOutput>false</CaptureTraceOutput>
    <DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>
    <DeploymentEnabled>False</DeploymentEnabled>
    <ConsiderFixturesAsSpecialTests>False</ConsiderFixturesAsSpecialTests>
    <AssemblyResolution>
      <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/>
    </AssemblyResolution>
</MSTest>

Configuração	Padrão	Valores
ForcedLegacyMode	falso	Em versões mais antigas do Visual Studio, o adaptador MSTest foi otimizado para torná-lo mais rápido e escalonável. Alguns comportamentos, como a ordem na qual os testes são executados, podem não ser exatamente como nas edições anteriores do Visual Studio. Defina o valor como verdadeiro para usar o adaptador de teste mais antigo. Por exemplo, você poderá usar essa configuração se tiver um arquivo app.config especificado para um teste de unidade. Recomendamos que você considere refatorar seus testes para permitir que você use o adaptador mais recente.
SettingsFile		Você pode especificar um arquivo de configurações de teste a ser usado com o adaptador MSTest aqui. Você também pode especificar um arquivo de configurações de teste no menu de configurações. Se você especificar esse valor, também será necessário definir o ForcedLegacyMode como true. `<ForcedLegacyMode>true</ForcedLegacyMode>`
DeploymentEnabled	verdadeiro	Se você definir o valor como falso, os itens de implantação especificados em seu método de teste não serão copiados para o diretório de implantação.
CaptureTraceOutput	verdadeiro	Capture mensagens de texto provenientes da API `Console.Write`, `Trace.Write`, `Debug.Write*` que serão associadas ao teste em execução atual.
EnableBaseClassTestMethodsFromOtherAssemblies	verdadeiro	Um valor que indica se é necessário habilitar a descoberta de métodos de teste de classes base em um assembly diferente da classe de teste herdada.
ClassCleanupLifecycle	EndOfClass	Se você quiser que a limpeza de classe ocorra no final do assembly, defina a opção como EndOfAssembly. (Não há mais suporte do MSTest v4 em diante, pois EndOfClass é o comportamento único e padrão de ClassCleanup)
MapNotRunnableToFailed	verdadeiro	Um valor que indica se um resultado não executável é mapeado como um teste falho.
Parallelize	Usado para definir as configurações de paralelização: Workers: o número de threads/funções de trabalho a serem usadas para paralelização, que é, por padrão, o número de processadores no computador atual. SCOPE: o escopo da paralelização. Você pode defini-lo como MethodLevel. Por padrão, é ClassLevel. `<Parallelize><Workers>32</Workers><Scope>MethodLevel</Scope></Parallelize>`
TestTimeout	0	Obtém o tempo limite de caso de teste global especificado.
TreatDiscoveryWarningsAsErrors	falso	Para relatar avisos de descoberta de teste como erros, defina este valor como true.
TreatClassAndAssemblyCleanupWarningsAsErrors	falso	Para ver as falhas nas limpezas de classe como erros, defina esse valor como true.
DeployTestSourceDependencies	verdadeiro	Um valor que indica se as referências de origem de teste devem ser implantadas.
DeleteDeploymentDirectoryAfterTestRunIsComplete	verdadeiro	Para manter o diretório de implantação após uma execução de teste, defina esse valor como falso.
MapInconclusiveToFailed	falso	Se um teste for concluído com um status inconclusivo, ele será mapeado para o status Ignorado no Gerenciador de Testes. Se você quiser que testes inconclusivos sejam mostrados como com falha, defina o valor como verdadeiro.
ConsiderFixturesAsSpecialTests	falso	Para exibir `AssemblyInitialize`, `AssemblyCleanup`, `ClassInitialize`, `ClassCleanup` como entradas individuais no Visual Studio e Visual Studio Code `Test Explorer` e `.trx` log, defina este valor como verdadeiro
AssemblyResolution	falso	Você pode especificar caminhos para assemblies extras ao localizar e executar testes de unidade. Por exemplo, use esses caminhos para as bibliotecas de dependência que não estão no mesmo diretório que a biblioteca de teste. Para especificar um caminho, use um elemento Caminho do Diretório. Os caminhos podem incluir variáveis de ambiente. `<AssemblyResolution> <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/> </AssemblyResolution>` Observe que esse recurso só está sendo aplicado ao usar o destino do .NET Framework.

Exemplo de arquivo .runsettings

O XML a seguir mostra o conteúdo de um típico arquivo de .runsettings. Copie este código e edite-o para atender às suas necessidades.

Cada elemento do arquivo é opcional porque tem um valor padrão.

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <!-- Configurations that affect the Test Framework -->
  <RunConfiguration>
    <!-- Use 0 for maximum process-level parallelization. This does not force parallelization within the test DLL (on the thread-level). You can also change it from the Test menu; choose "Run tests in parallel". Unchecked = 1 (only 1), checked = 0 (max). -->
    <MaxCpuCount>1</MaxCpuCount>
    <!-- Path relative to directory that contains .runsettings file-->
    <ResultsDirectory>.\TestResults</ResultsDirectory>

    <!-- Omit the whole tag for auto-detection. -->
    <!-- [x86] or x64, ARM, ARM64, s390x  -->
    <!-- You can also change it from the Test menu; choose "Processor Architecture for AnyCPU Projects" -->
    <TargetPlatform>x86</TargetPlatform>

    <!-- Any TargetFramework moniker or omit the whole tag for auto-detection. -->
    <!-- net48, [net40], net6.0, net5.0, netcoreapp3.1, uap10.0 etc. -->
    <TargetFrameworkVersion>net40</TargetFrameworkVersion>

    <!-- Path to Test Adapters -->
    <TestAdaptersPaths>%SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar</TestAdaptersPaths>

    <!-- TestCaseFilter expression -->
    <TestCaseFilter>(TestCategory != Integration) &amp; (TestCategory != UnfinishedFeature)</TestCaseFilter>

    <!-- TestSessionTimeout was introduced in Visual Studio 2017 version 15.5 -->
    <!-- Specify timeout in milliseconds. A valid value should be greater than 0 -->
    <TestSessionTimeout>10000</TestSessionTimeout>

    <!-- true or false -->
    <!-- Value that specifies the exit code when no tests are discovered -->
    <TreatNoTestsAsError>true</TreatNoTestsAsError>
  </RunConfiguration>

  <!-- Configurations for data collectors -->
  <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>
            <ModulePaths>
              <Exclude>
                <ModulePath>.*CPPUnitTestFramework.*</ModulePath>
              </Exclude>
            </ModulePaths>

            <!-- We recommend you do not change the following values: -->
            <UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
            <AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
            <CollectFromChildProcesses>True</CollectFromChildProcesses>
            <CollectAspDotNet>False</CollectAspDotNet>

          </CodeCoverage>
        </Configuration>
      </DataCollector>

      <DataCollector uri="datacollector://microsoft/VideoRecorder/1.0" assemblyQualifiedName="Microsoft.VisualStudio.TestTools.DataCollection.VideoRecorder.VideoRecorderDataCollector, Microsoft.VisualStudio.TestTools.DataCollection.VideoRecorder, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" friendlyName="Screen and Voice Recorder">
        <!--Video data collector was introduced in Visual Studio 2017 version 15.5 -->
        <Configuration>
          <!-- Set "sendRecordedMediaForPassedTestCase" to "false" to add video attachments to failed tests only -->
          <MediaRecorder sendRecordedMediaForPassedTestCase="true"  xmlns="">           
            <ScreenCaptureVideo bitRate="512" frameRate="2" quality="20" />
          </MediaRecorder>
        </Configuration>
      </DataCollector>

      <!-- Configuration for blame data collector -->
      <DataCollector friendlyName="blame" enabled="True">
      </DataCollector>

    </DataCollectors>
  </DataCollectionRunSettings>

  <!-- Parameters used by tests at run time -->
  <TestRunParameters>
    <Parameter name="webAppUrl" value="http://localhost" />
    <Parameter name="webAppUserName" value="Admin" />
    <Parameter name="webAppPassword" value="Password" />
  </TestRunParameters>

  <!-- Configuration for loggers -->
  <LoggerRunSettings>
    <Loggers>
      <Logger friendlyName="console" enabled="True">
        <Configuration>
            <Verbosity>quiet</Verbosity>
        </Configuration>
      </Logger>
      <Logger friendlyName="trx" enabled="True">
        <Configuration>
          <LogFileName>foo.trx</LogFileName>
        </Configuration>
      </Logger>
      <Logger friendlyName="html" enabled="True">
        <Configuration>
          <LogFileName>foo.html</LogFileName>
        </Configuration>
      </Logger>
      <Logger friendlyName="blame" enabled="True" />
    </Loggers>
  </LoggerRunSettings>

  <!-- Adapter Specific sections -->

  <!-- MSTest adapter -->
  <MSTest>
    <MapInconclusiveToFailed>True</MapInconclusiveToFailed>
    <CaptureTraceOutput>false</CaptureTraceOutput>
    <DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>
    <DeploymentEnabled>False</DeploymentEnabled>
    <AssemblyResolution>
      <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/>
    </AssemblyResolution>
  </MSTest>

</RunSettings>

Especificar variáveis de ambiente no arquivo .runsettings do

As variáveis de ambiente podem ser definidas no arquivo .runsettings, que pode interagir diretamente com o host de teste. Especificar variáveis de ambiente no arquivo .runsettings é necessário para dar suporte a projetos nãotriviais que exigem a definição de variáveis de ambiente como DOTNET_ROOT. Essas variáveis são definidas durante a geração do processo de host de teste e estão disponíveis no host.

Exemplo

O código a seguir é um arquivo .runsettings de exemplo que passa variáveis de ambiente:

<?xml version="1.0" encoding="utf-8"?>
<!-- File name extension must be .runsettings -->
<RunSettings>
  <RunConfiguration>
    <EnvironmentVariables>
      <!-- List of environment variables we want to set-->
      <DOTNET_ROOT>C:\ProgramFiles\dotnet</DOTNET_ROOT>
      <SDK_PATH>C:\Codebase\Sdk</SDK_PATH>
    </EnvironmentVariables>
  </RunConfiguration>
</RunSettings>

O nó RunConfiguration deve conter um nó EnvironmentVariables. Uma variável de ambiente pode ser especificada como um nome de elemento e seu valor.

Nota

Como essas variáveis de ambiente sempre devem ser definidas quando o host de teste é iniciado, os testes sempre devem ser executados em um processo separado. Para isso, o sinalizador /InIsolation será definido quando houver variáveis de ambiente para que o host de teste seja sempre invocado.

Compartilhar via

Configurar testes de unidade usando um arquivo .runsettings

Criar um arquivo de configurações de execução e personalizá-lo

Especificar um arquivo de configurações de execução no IDE

Visual Studio 2019 versão 16.4 e posterior

Autodetectar o arquivo de configurações de execução

Selecione manualmente o arquivo de configurações de execução

Definir uma propriedade de compilação

Visual Studio 2019 versão 16.3 e anterior

Especificar um arquivo de configurações de execução da linha de comando

O arquivo *.runsettings

Elemento RunConfiguration

Elemento DataCollectors (adaptadores de dados de diagnóstico)

Coletor de dados CodeCoverage

Coletor de dados VideoRecorder

Culpar o coletor de dados

ParâmetrosDeExecuçãoDeTeste

Elemento LoggerRunSettings

Elemento MSTest

Exemplo de arquivo .runsettings

Especificar variáveis de ambiente no arquivo .runsettings do

Exemplo

Comentários

Recursos adicionais

Compartilhar via

Configurar testes de unidade usando um arquivo .runsettings

Criar um arquivo de configurações de execução e personalizá-lo

Especificar um arquivo de configurações de execução no IDE

Visual Studio 2019 versão 16.4 e posterior

Autodetectar o arquivo de configurações de execução

Selecione manualmente o arquivo de configurações de execução

Definir uma propriedade de compilação

Visual Studio 2019 versão 16.3 e anterior

Especificar um arquivo de configurações de execução da linha de comando

O arquivo *.runsettings

Elemento RunConfiguration

Elemento DataCollectors (adaptadores de dados de diagnóstico)

Coletor de dados CodeCoverage

Coletor de dados VideoRecorder

Culpar o coletor de dados

ParâmetrosDeExecuçãoDeTeste

Elemento LoggerRunSettings

Elemento MSTest

Exemplo de arquivo .runsettings

Especificar variáveis de ambiente no arquivo .runsettings do

Exemplo

Conteúdo relacionado

Comentários

Recursos adicionais