Configurar testes de unidade usando um ficheiro de .runsettings

Artigo
01/27/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 ficheiro .runsettings é personalizar a análise de cobertura de código .

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

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

Crie um arquivo de configurações de execução e personalize-o

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

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

Dica

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

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

Dica

Você pode criar mais de um arquivo de .runsettings 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.

Detetar automaticamente as configurações de execução
Definir manualmente as configurações de execução
Definir uma propriedade de compilação

Detetar automaticamente o arquivo de configurações de execução

Observação

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

Para detetar automaticamente o arquivo de configurações de execução, coloque-o na raiz da sua solução.

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

Selecione Ferramentas>Opções>Testar>Detetar automaticamente os arquivos runsettings
Selecione Test>Configurar Definições de Execução>Deteção Automática de Ficheiros runsettings

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

No IDE, selecione Test>Configure Run Settings>Select Solution Wide runsettings Filee, em seguida, selecione o arquivo .runsettings.

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

Selecionar ficheiro de configuração runsettings para toda a solução de teste no Visual Studio

Definir uma propriedade de compilação

Adicione uma propriedade 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 para um projeto é especificado pela propriedade RunSettingsFilePath.

As configurações de execução no nível do projeto são atualmente suportadas 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é ao ficheiro .runsettings e selecione-o.

Selecionar ficheiro de configurações de teste no menu do Visual Studio 2019

O arquivo aparece no menu Testar e você pode selecioná-lo ou desmarcá-lo. Quando selecionado, o ficheiro de definições de execução aplica-se sempre que se seleciona Analisar cobertura de código.

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

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

Abra Linha de Comandos 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 escrever 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 é executada em seu próprio processo testhost e é 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 dentro de uma DLL (no nível de thread) depende da estrutura 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 quantos você tiver processadores lógicos (por exemplo, 6, para um computador com 6 núcleos físicos sem multi-threading, ou 12, para um computador com seis núcleos físicos com multi-threading). O número de DLLs distintas na execução determina o número real de testhosts iniciados.
DiretórioDeResultados		O diretório onde 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 tag para detetar automaticamente. Essa configuração define a versão da estrutura ou a família de estruturas a ser usada para executar testes. Os valores aceitos são qualquer apelido de estrutura como `net48`, `net472`,`net6.0`, `net5.0`, `netcoreapp3.1`, `uap10.0` ou qualquer nome de estrutura completo válido, como`.NETFramework,Version=v4.7.2` ou `.NETCoreApp,Version=v6.0.0`. Para compatibilidade com versões anteriores `Framework35`, `Framework40`, `Framework45`, `FrameworkCore10`, `FrameworkUap10` são aceitos, significando (`net35`, `net40`, `net45`, `netcoreapp1.0` e `uap10.0` respectivamente). Todos os valores não diferenciam maiúsculas de minúsculas. O valor fornecido é usado para determinar o provedor de tempo de execução de teste a ser usado. Cada provedor de tempo de execução 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 que foi criado com a versão exata especificada é usado. Para valores fora desse intervalo, o .NET Framework 4.5.1 testhost é 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 que é usada. Omita o elemento `TargetFrameworkVersion` do arquivo de .runsettings do para determinar automaticamente a versão da estrutura a partir dos binários construídos. Ao detetar 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 executável do .NET Framework (no Visual Studio ou vstest.console.exe na linha de comandos do desenvolvedor), a estrutura de destino comum é o net40. Para o corredor .NET (dotnet test + DLLs), a estrutura de destino comum é definida como netcoreapp1.0.
TargetPlatform	x86	Omita toda essa tag para detetar 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 detetar automaticamente, a arquitetura para DLLs AnyCPU pode diferir com base no executante. Para o corredor do .NET Framework (no Visual Studio, ou vstest.console.exe na linha de comando do desenvolvedor), o padrão é x86. Para o .NET runner (dotnet test), o padrão é a arquitetura de processo atual.
TreatTestAdapterErrorsAsWarnings	falso	falso, verdadeiro
TestAdaptersPaths		Um ou mais caminhos para o diretório onde os TestAdapters estão localizados
TestCaseFilter		Uma expressão de filtro no formato de propriedade <><operador><valor>[\|&<Expressão>]. O operador booleano & deve ser representado pela entidade HTML &. As expressões podem ser colocadas entre parênteses. Para obter uma sintaxe detalhada sobre a estrutura da expressão, consulte vstest/docs/filter.md.
SessãoDeTesteExpirada		Permite que os usuários encerrem uma sessão de teste quando ela exceder um determinado tempo limite, especificado em milissegundos. Definir 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 em Visual Studio 2017 versão 15.5 e posterior.
DotnetHostPath		Especifique um caminho personalizado para o host dotnet que é usado para executar o testhost. É útil quando você está criando seu próprio dotnet, por exemplo, ao criar o repositório dotnet/runtime. Especificar esta opção ignora a procura de testhost.exee obriga o uso de testhost.dll.
TreatNoTestsAsError	falso	verdadeiro ou falso Especifique um valor booleano, 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, zero é retornado.

Elemento DataCollectors (adaptadores de dados de diagnóstico)

O DataCollectors elemento especifica configurações de adaptadores de dados de diagnóstico. Os adaptadores de dados de diagnóstico reúnem 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 de quais partes do código do aplicativo foram exercidas no teste. Para obter informações detalhadas sobre como personalizar as configurações de cobertura de código, consulte Personalizar 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>

VideoRecorder coletor de dados

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, consulte o Exemplo de arquivo *.runsettings.

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

Culpe 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 falha: para criar um despejo quando testhost falha
Modo de despejo suspenso: para criar um despejo quando o teste não termina antes de determinado tempo limite

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 o NUnit TestContext):

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, Visual Studio Test Results File (trx) e 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
ModoHerdeiroForçado	falso	Em versões mais antigas do Visual Studio, o adaptador MSTest foi otimizado para torná-lo mais rápido e escalável. Alguns comportamentos, como a ordem em que os testes são executados, podem não ser exatamente como era em edições anteriores do Visual Studio. Defina o valor como true para usar o adaptador de teste mais antigo. Por exemplo, você pode usar essa configuração se tiver um arquivo de app.config especificado para um teste de unidade. Recomendamos que você considere a refatoração de seus testes para permitir que você use o adaptador mais recente.
ConfiguraçõesArquivo		Você pode especificar um arquivo de configurações de teste para usar com o adaptador MSTest aqui. Você também pode especificar um arquivo de configurações de teste no menu de configurações. Se especificares esse valor, também deves definir o ForcedLegacyMode como true. `<ForcedLegacyMode>true</ForcedLegacyMode>`
DeploymentEnabled	verdadeiro	Se você definir o valor como falso, os itens de implantação especificados no método de teste não serão copiados para o diretório de implantação.
CaptureTraceOutput	verdadeiro	Capture mensagens de texto provenientes de `Console.Write`, `Trace.WriteDebug.Write*` api que serão associadas ao teste em execução atual.
EnableBaseClassTestMethodsFromOtherAssemblies	verdadeiro	Um valor que indica se a descoberta de métodos de teste a partir de classes base, em um assembly diferente da classe de teste herdeira, deve ser habilitada.
ClassCleanupLifecycle	Fim de Classe	Se desejar que a limpeza de classe ocorra no final da montagem, defina-a como EndOfAssembly. (Não há mais suporte a partir do MSTest v4, pois EndOfClass é o padrão e apenas ClassCleanup comportamento)
MapNotRunnableToFailed	verdadeiro	Um valor que indica se um resultado não executável é mapeado para teste com falha.
Paralelizar	Usado para definir as configurações de paralelização: Workers: O número de threads/trabalhadores a usar para paralelização, que é por padrão o número de processadores da máquina atual. ESCOPO: 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 especificado para o caso de teste global.
TratarAvisosDeDescobertaComoErros	falso	Para relatar avisos de descoberta de testes como erros, defina este valor como true.
pt-PT: TreatClassAndAssemblyCleanupWarningsAsErrors	falso	Para ver suas falhas em limpezas de classe como erros, defina esse valor como true.
ImplementarTesteFontesDependências	verdadeiro	Um valor que indica se as referências de origem de teste devem ser implantadas.
EliminarDiretórioDeImplantaçãoApósConclusãoDoTeste	verdadeiro	Para manter o diretório de implantação após uma execução de teste, defina esse valor como false.
MapInconclusiveToFailed	falso	Se um teste for concluído com um status inconclusivo, ele será mapeado para o status ignorado em Gerenciador de Testes. Se desejar que os testes inconclusivos sejam mostrados como reprovados, defina o valor como true.
ConsiderarInstalaçõesComoTestesEspeciais	falso	Para exibir `AssemblyInitialize`, `AssemblyCleanup`, `ClassInitializeClassCleanup` como entradas individuais no Visual Studio e no Visual Studio Code `Test Explorer` e no log de `.trx`, defina esse valor como true
Resolução de Assembleia	falso	Você pode especificar caminhos para assemblies extras ao localizar e executar testes de unidade. Por exemplo, utilize estes caminhos para conjuntos de dependência que não se encontram no mesmo diretório que o conjunto de teste. Para especificar um caminho, use um elemento Directory Path. 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 arquivo de .runsettings

O seguinte XML mostra o conteúdo de um ficheiro .runsettings típico. Copie este código e edite-o de acordo com as 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>

Especifique variáveis de ambiente no ficheiro .runsettings do

As variáveis de ambiente podem ser definidas no ficheiro .runsettings, que pode interagir diretamente com o host de teste. A especificação de variáveis de ambiente no arquivo de .runsettings do é necessária para dar suporte a projetos não triviais 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 exemplo arquivo .runsettings 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.

Observação

Como essas variáveis de ambiente sempre devem ser definidas quando o host de teste é iniciado, os testes devem sempre 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.

Partilhar via

Configurar testes de unidade usando um ficheiro de .runsettings

Crie um arquivo de configurações de execução e personalize-o

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

Visual Studio 2019 versão 16.4 e posterior

Detetar automaticamente 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 na linha de comando

O arquivo *.runsettings

Elemento RunConfiguration

Elemento DataCollectors (adaptadores de dados de diagnóstico)

Coletor de dados CodeCoverage

VideoRecorder coletor de dados

Culpe o coletor de dados

ParâmetrosDeExecuçãoDeTeste

Elemento LoggerRunSettings

Elemento MSTest

Exemplo arquivo de .runsettings

Especifique variáveis de ambiente no ficheiro .runsettings do

Exemplo

Comentários

Recursos adicionais

Partilhar via

Configurar testes de unidade usando um ficheiro de .runsettings

Crie um arquivo de configurações de execução e personalize-o

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

Visual Studio 2019 versão 16.4 e posterior

Detetar automaticamente 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 na linha de comando

O arquivo *.runsettings

Elemento RunConfiguration

Elemento DataCollectors (adaptadores de dados de diagnóstico)

Coletor de dados CodeCoverage

VideoRecorder coletor de dados

Culpe o coletor de dados

ParâmetrosDeExecuçãoDeTeste

Elemento LoggerRunSettings

Elemento MSTest

Exemplo arquivo de .runsettings

Especifique variáveis de ambiente no ficheiro .runsettings do

Exemplo

Conteúdo relacionado

Comentários

Recursos adicionais